123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117 |
- rbm_steps(7)
- ============
- NAME
- ----
- rbm_steps - rbm steps configuration
- DESCRIPTION
- -----------
- When you define some project, you can have more than one script
- definition, for the different steps of the build process (build, test,
- publish, etc ...), or for different types of packaging (rpm, deb, etc
- ...).
- All the configuration options are shared between all those scripts.
- However, in some cases you may want some option to have a different value
- depending of the script that we are running. The name of the script we
- are going to be running is called the 'step', and it is possible to have
- different option values depending on the current step.
- CONFIGURATION
- -------------
- The first way to have a different option value depending on the curernt
- step is to use the IF/ELSE template directives and the +step+ option.
- The +step+ option contains the name of the current step. For instance
- if you want to use a different git tag or branch for rpm and debian
- packages, you could do:
- ----
- git_hash: |
- [% IF c('step') == 'rpm' -%]
- dev-rpm
- [%- ELSIF c('step') == 'deb' -%]
- dev-deb
- [%- ELSE -%]
- dev
- [%- END -%]
- ----
- An other way to do it is to use +steps+ option. This option works in a
- similar way to the +targets+ option except that it contains a hash
- indexed by step name rather than a hash indexed by target name..
- The steps configuration can be defined in any of the configuration files,
- using the +steps+ option. This option is an hash, with the steps names
- as keys, and as value an other hash containing the options to be used
- for this step.
- A project which should use a different git tag or branch depending on
- whether we are building an rpm or deb package could be defined in the following way:
- ----
- git_hash: dev
- steps:
- rpm:
- git_hash: dev-rpm
- deb:
- git_hash: dev-deb
- ----
- It is also possible to combine step based configuration with target
- configuration. For instance you could do:
- ----
- targets:
- stable:
- git_hash: stable
- dev:
- git_hash: dev
- steps:
- rpm:
- targets:
- stable:
- git_hash: stable-rpm
- dev:
- git_hash: dev-rpm
- deb:
- targets:
- stable:
- git_hash: stable-deb
- dev:
- git_hash: dev-deb
- ----
- If the value of a step is not a hash containing options, but a string,
- then this name is used as step name. This can be used to alias a step
- configuration to an other step. For instance you usually want to use
- the same options for the rpm and srpm scripts. The default configuration
- includes the following steps aliases:
- - srpm: rpm
- - deb-src: deb
- PRE AND POST SCRIPTS
- --------------------
- Before starting some build script, you often need to prepare the host
- for the build. Usually this means installing some dependencies required
- for the build. After the build finished, you might want to remove those
- dependencies that have been added.
- This can be done using the +pre+ and +post+ options. Those options
- contains a script that is run as root before and after the build. Those
- options can be defined globally, or per step.
- The +pre+ and +post+ scripts are expected to be run as root. To do that,
- they are run using the +suexec+ option if run locally, or if run using
- the +remote_exec+ option the +exec_as_root+ option is set to true. The
- +suexec+ option takes the +suexec_cmd+ option and runs it as root. By
- default, the +suexec+ option uses sudo.
- SEE ALSO
- --------
- link:rbm.html[rbm(1)],
- link:rbm_config.html[rbm_config(7)]
|