1RBM_TARGETS(7) RBM_TARGETS(7)
2
6 rbm_targets - rbm targets configuration
7
9 When you are building packages you might want to build them in
10 different situations, with different options. The targets allow you to
11 define those options.
12 For instance you could be doing nightly builds of your packages, local
14 test builds when you are working on the developpement of a new feature,
15 and from time to time build a package for a new release. In such
16 situation, you could use command line arguments to change the options,
17 or change the config file each time, but that is not very convenient.
18 Instead you can define targets with any number of options, and use a
19 single argument to select the target.
20
22 The targets can be defined in any of the configuration files, using the
23 targets option. This option is an hash, with the target names as keys,
24 and as value an other hash containing the options to be used for this
25 target.
26 As an example we could define the following targets :
28 • the dev target, for daily development, from the master branch. You
30 want to automatically fetch from the git repository before each
31 build, and you want to check that the commit used is signed by a
32 key from the developers.gpg keyring.
33 • the release target, for building packages for a new release. You
35 only want to build them from gpg signed tags, signed by the key
36 from the release.gpg keyring.
37 In such case, the following targets configuration could be used :
39 targets:
41 dev:
42 git_hash: master
43 fetch: 1
44 commit_gpg_id: 1
45 gpg_keyring: developers.gpg
46 release:
47 tag_gpg_id: 1
48 gpg_keyring: release.gpg
49 If the value of a target is not a hash containing options, but a string
51 or an array of strings, then this or those names are used as targets.
52 This is useful if you want to say that a target is the same as an other
53 one, or to extend a target.
54 You can use this if you want to set a default target. When no target
56 has been selected, the notarget target is used. In this example, we set
57 dev as the default target:
58 targets:
60 notarget: dev
61 dev:
62 git_hash: master
63 fetch: 1
64 commit_gpg_id: 1
65 gpg_keyring: developers.gpg
66 release:
67 tag_gpg_id: 1
68 gpg_keyring: release.gpg
69 In this example we extend the release target as release_1 to add a
71 git_hash:
72 targets:
74 release_1:
75 - git_hash_version_1
76 - release
77 release:
78 tag_gpg_id: 1
79 gpg_keyring: release.gpg
80 git_hash_version_1:
81 git_hash: version-1.0
82
84 The target to be used can be selected with the --target command line
85 option. You can select more than one target by giving the option
86 multiple times, and in this case they will be used in the order given
87 on the command line. If no target is selected, then the notarget target
88 is used.
89 For example, if you want to build a debian package (assuming that you
91 defined a deb step for that) for the dev target:
92 $ rbm build --step deb --target dev
94 If you want to build a debian package for the release target, using the
96 0.1.2.3 tag:
97 $ rbm build --step deb --target release --git-hash 0.1.2.3
99 Sometime, an option in one project will use the value of an option from
101 an other project (with the pc template function, see rbm_templates(7)
102 for details), or a project will use the output of an other project as
103 input file (see rbm_input_files(7) for details). In such cases, you may
104 want to select a target to be applied only for a specific project. This
105 can be done with the following syntax:
106 $ rbm build --target project:target
108
110 rbm(1), rbm_config(7),
111 07/28/2023 RBM_TARGETS(7)