RBM_STEPS(7)

✨ RBM_STEPS ✨

okay bestie, so this is the page for rbm_steps — aka rbm steps configuration 💅 pull up a chair, we're gonna talk about how to make your build scripts act different depending on which step they're on. no cap.

---

🌸 DESCRIPTION 🌸

so when you define a project, you can have more than one script definition — like, one for each step of the build process (build, test, publish, etc ...), or one for each type of packaging (rpm, deb, etc ...). iconic, right?

and here's the thing: all the configuration options are shared between all those scripts. like, everybody gets the same options. but sometimes? you want one option to have a different value depending on which script is actually running. that script name is what we call the step ✨ and yes, you can totally have different option values depending on the current step.

---

🎀 CONFIGURATION 🎀

the IF/ELSE way 💖

the first way to get a different option value depending on the current step is to use the IF/ELSE template directives plus the step option. the step option literally contains the name of the current step, periodt.

so say you defined rpm and deb steps for building rpm and debian packages, and you want a different git tag or branch depending on the type of package. you'd do:

git_hash: |
 [% IF c('step') == 'rpm' -%]
 dev-rpm
 [%- ELSIF c('step') == 'deb' -%]
 dev-deb
 [%- ELSE -%]
 dev
 [%- END -%]

the steps option way 🦋

another way to do it is the steps option. it works kinda like the targets option except it's 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. it's a hash where the keys are the step names, and each value is another hash containing the options to be used for that step. nesting. we love to see it.

a project that should use a different git tag or branch depending on whether we're building an rpm or deb package could be defined like this:

git_hash: dev
steps:
  rpm:
    git_hash: dev-rpm
  deb:
    git_hash: dev-deb

combining steps + targets 🌈

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

step aliases 👑

if the value of a step is not a hash containing options, but a string, then this name is used as the 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, which can be done with the following step alias:

• srpm: rpm

---

🫶 PRE AND POST SCRIPTS 🫶

before starting some build script, you often need to prepare the host for the build. usually that means installing some dependencies required for the build. and after the build finishes, you might want to remove those dependencies that have been added. clean up after yourself, bestie 🧹✨

this can be done using the pre and post options. those options contain a script that is run as root before and after the build. and yes, those options can be defined globally, or per step. your choice 💁

⚠️ the pre and post scripts are expected to be run as root, okay? 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. so yeah, root energy only 🔥

---

⭐ SEE ALSO ⭐

• rbm(1)
• rbm_config(7)

---

and that's the whole vibe check 💖 this was the rbm_steps page, dated 07/25/2025 — go forth and configure your steps, you absolute main character 🌸🦋💅