rbm_targets - Man Page

When you are building packages you might want to build them in different situations, with different options. The targets allow you to define those options.

For instance you could be doing nightly builds of your packages, local test builds when you are working on the developpement of a new feature, and from time to time build a package for a new release. In such situation, you could use command line arguments to change the options, or change the config file each time, but that is not very convenient. Instead you can define targets with any number of options, and use a single argument to select the target.

The targets can be defined in any of the configuration files, using the targets option. This option is an hash, with the target names as keys, and as value an other hash containing the options to be used for this target.

As an example we could define the following 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, the following 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

If the value of a target is not a hash containing options, but a string or an array of strings, then this or those names are used as targets. This is useful if you want to say that a target is the same as an other one, or to extend a target.

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

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

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. If no target is selected, then the notarget target is used.

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

rbm(1), rbm_config(7),

rbm(1), rbm_cli(7), rbm_config(7).