RBM_TARGETS(7)

📦
version 0.4^20241205gitc6a4095 · 2 versions
, in fedora 43

💖 RBM_TARGETS(7) 💖

okay bestie, so this is the rbm_targets manual — it's section 7, it lives in the RBM_TARGETS(7) corner of the manpage universe, and it's literally all about targets configuration. grab a strawberry 🍓 and let's get into it.

✨ NAME ✨

rbm_targets — the rbm targets configuration, aka the thing that lets you save whole vibes as named presets instead of retyping flags like a clown 💅

🌸 DESCRIPTION 🌸

so when you're building packages you might wanna build them in different situations, with different options. and that's the whole point of targets: they let you define those options once. no cap.

like, picture this: you're doing nightly builds of your packages 🌙, and also local test builds while you're working on the development of a new feature 🧪, and every once in a while you build a package for a new release 🎀. in that situation you could just use command line arguments to change the options, or edit the config file every single time, but bestie… that is not very convenient. not it. 🙈

instead? you define targets with any number of options, and then you select the whole vibe with a single argument. iconic.

🎀 CONFIGURATION 🎀

targets can be defined in any of the configuration files, using the targets option. this option is a hash — the target names are the keys, and the value is another hash containing the options to be used for that target. hash-in-hash, inception core 💫

as an example, we could define these targets:

  • the dev target, for daily development, from the master branch. you want to automatically fetch from the git repository before each build, and you want to check that the commit used is signed by a key from the developers.gpg keyring. 🔑
  • the release target, for building packages for a new release. you only want to build them from gpg signed tags, signed by the key from the release.gpg keyring. 👑

in such case, this targets configuration could be used:

targets:
  dev:
    git_hash: master
    fetch: 1
    commit_gpg_id: 1
    gpg_keyring: developers.gpg
  release:
    tag_gpg_id: 1
    gpg_keyring: release.gpg

okay but here's the slay part ✨ — if the value of a target is not a hash containing options, but a string or an array of strings, then that name (or those names) are used as targets. this is useful if you wanna say that a target is the same as another one, or to extend a target. it's giving inheritance, it's giving reusing your own work, we love to see it 🫶

you can use this if you want to set a default target. when no target has been selected, the notarget target is used. in this example, we set dev as the default target:

targets:
  notarget: dev
  dev:
    git_hash: master
    fetch: 1
    commit_gpg_id: 1
    gpg_keyring: developers.gpg
  release:
    tag_gpg_id: 1
    gpg_keyring: release.gpg

and in this example we extend the release target as release_1 to add a git_hash:

targets:
  release_1:
   - git_hash_version_1
   - release
  release:
    tag_gpg_id: 1
    gpg_keyring: release.gpg
  git_hash_version_1:
    git_hash: version-1.0

see how release_1 just collects a list and stacks them? main character energy fr fr 👑

🔥 COMMAND LINE OPTION 🔥

the target to be used can be selected with the --target command line option. you can select more than one target by giving the option multiple times, and in this case they will be used in the order given on the command line. order matters, bestie, don't play with it 📋

if no target is selected, then the notarget target is used. (yes, again. it's the fallback bae.)

for example, if you want to build a debian package (assuming that you defined a deb step for that) for the dev target:

$ rbm build --step deb --target dev

if you want to build a debian package for the release target, using the 0.1.2.3 tag:

$ rbm build --step deb --target release --git-hash 0.1.2.3

sometime, an option in one project will use the value of an option from an other project (with the pc template function — see rbm_templates(7) for details), or a project will use the output of an other project as input file (see rbm_input_files(7) for details). in such cases, you may want to select a target to be applied only for a specific project. this can be done with the following syntax:

$ rbm build --target project:target

so it's project:target, colon between them, no spaces, exactly like that. 💅

ngl, that project:target syntax is the sneaky little detail everyone forgets, and then they're confused why their build is weird. don't be that person. 🙈

👑 SEE ALSO 👑

and that's the whole page, bestie!! go forth and target responsibly 💜

this little love letter was brought to you by the RBM_TARGETS(7) source, dated 07/25/2025. mwah 🎀✨💖

📦 where this page comes from