A Workflow is a collection of Steps, Environment Variables, and other configurations for a single
Defining a workflow ⚓
The only requirement for a Workflow is an ID. As an example, in this configuration we declared one Workflow with the ID
format_version: 1.3.1 workflows: test:
You can define multiple Workflows and run a specific Workflow with
bitrise run WORKFLOWID. Below configuration contains two Workflows,
second, so you can execute both
bitrise run first and
bitrise run second.
format_version: 1.3.1 workflows: first: second:
Adding Steps to a Workflow ⚓
To add Steps to a Workflow simply include
steps: and then add the Step(s).
For example, here is how to run two Script Steps after each other:
format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git workflows: test: steps: - script: title: First step - script: title: Second step
When you run
bitrise run test, the Bitrise CLI will run the two script Steps one by one, starting with the
First step and then continuing with the
Defining Workflow-specific parameters and Environment Variables ⚓
Besides Steps you can also specify Environment Variables for every Workflow.
A Workflow’s Environment Variables are used when the Workflow is executed, and are available for every Step in the Workflow.
Here is an example for defining two Environment Variables (
ENV_VAR_TWO) in the
format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git workflows: test: envs: - ENV_VAR_ONE: first value - ENV_VAR_TWO: second value
Chaining Workflows and reusing Workflows ⚓
You can chain Workflows to run one/multiple Workflows(s) before and/or after a specific Workflow.
Example Workflow for chaining five Workflows:
format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git workflows: send-notifications: steps: # send notifications setup: steps: # setup Steps to run test: before_run: - setup envs: - IS_TEST: "true" steps: # test Steps to run ci: before_run: - test after_run: - send-notifications deploy: before_run: - test steps: # steps to deploy after_run: - send-notifications
Based on the above example, if you run:
bitrise run send-notifications: only the Steps of the
send-notificationsworkflow will be executed.
bitrise run setup: only the Steps of the
setupWorkflow will be executed.
bitrise run test: first the Steps of the
setupWorkflow will be executed, then the Steps declared in
bitrise run ci: will execute the Steps of the Workflows in the following order:
ciWorkflow doesn’t have any Steps, but that’s not an issue. It just means that no Step will be executed here and the build will continue with the next Workflow in the chain).
bitrise run deploy: will execute the Steps of the Workflows in the following order:
This means that you can define what a
test should do in your project in the
test Workflows only once, and then you can reuse those in other Workflows. There’s no need to duplicate Steps between Workflows.
To sum it up, when you chain Workflows, it’s the same as if you’d create one Workflow which would include all Steps from all the Workflows chained after each other. So, for example, one Step’s outputs will be available for every other Step which is executed after that Step during the build, (regardless of whether the other Step is in the same or in another Workflow). If a Step is executed after another Step during the build, it can access the outputs of the previous Steps.
About Workflow Environment Variables ⚓
Workflow specific Environment Variables are made accessible when the Workflow is executed. These Environment Variables are available for Workflows executed after that Workflow, but not in the ones executed before that Workflow.
For example, if you
bitrise run ci, the
IS_TEST Environment Variable won’t be available in the
setup Workflow, as that runs before the
IS_TEST will be available for the Steps in
This is true even if the Workflow doesn’t have any Steps. This can be utilized if you want to create generic Workflows, which can do different things based on Environment Variables, and you specify those Environment Variables through a wrapper Workflow.
format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git workflows: generic-build: steps: # steps which depend on `BUILD_TYPE` environment variable build-alpha: envs: - BUILD_TYPE: alpha after_run: - generic-build build-beta: envs: - BUILD_TYPE: beta after_run: - generic-build
As you can see in the above example, neither
build-beta Workflows have any Steps. Instead the Steps are defined in
generic-build, but when you
bitrise run build-alpha the
BUILD_TYPE Environment Variable will be set to
alpha, while if you
bitrise run build-beta, the
BUILD_TYPE Environment Variable will be set to
As discussed above, Workflow defined Environment Variables are only available in the Workflow it defines, and in the ones executed after that Workflow. So in our example,
generic-build is included as
after_run Workflow, therefore, the
BUILD_TYPE Environment Variable will be available in the Steps of
generic-build. But if you use
before_run instead of
after_run, that means that technically the steps of
generic-build are processed and executed before processing the
build-beta workflows, so the
BUILD_TYPE Environment Variable would not be available in the Step of
Utility Workflows ⚓
Utility Workflows help you organize your Workflows more efficiently.
If you chain Workflows together, you might quickly end up with tons of small, reusable workflows. Finding the right workflow might get a bit tricky. Utility workflows to the rescue! The Bitrise CLI supports a small notation, called utility workflow: a workflow whose ID starts with an underscore character, for example,
You can find utility workflows at the end of the workflow list if you run
bitrise run or
bitrise workflows. Mind you, utility workflows can’t be executed directly with a
bitrise run command. These workflows can be referenced in
Using the above example with five workflows (
test), if you run
bitrise run in the directory of the
bitrise.yml without specifying a Workflow, you’ll get list of all five Workflows:
The following workflows are available: * ci * deploy * send-notifications * setup * test You can run a selected workflow with: $ bitrise run WORKFLOW-ID
You most likely don’t want to run
send-notifications by itself, only through
deploy. If you prefix those with an underscore character to make them utility Workflows, the
bitrise run output will better highlight which Workflows are meant to be executed directly:
The following workflows are available: * ci * deploy You can run a selected workflow with: $ bitrise run WORKFLOW-ID The following utility workflows are defined: * _send-notifications * _setup * _test Note about utility workflows: Utility workflow names start with '_' (example: _my_utility_workflow). These workflows can't be triggered directly, but can be used by other workflows in the before_run and after_run lists.
The configuration format of the Bitrise CLI is referred to as bitrise.yml. This is the expected file name the configuration should be saved with.
Any tool that can edit `bitrise.yml` can add custom properties to it. This way you can add special properties or notes to your env vars, or even try new configurations...
To understand Bitrise in depth, there are a few key concepts that must be kept in mind. These are immutable and crucial to the way we do things.