GitHub

Most important concepts

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.

Every input, output and parameter is an Environment Variable

Every input and variable in your build configuration is an environment variable. For example:

There’s nothing special about how Bitrise handles environment variables. These are all regular environment variables, with the same rules and restrictions as any other environment variable.

Of course, there are some technical details that should be kept in mind. We’ll go over some of them.

The value of an Environment Variable can only be a String

Environment Variables can only hold String values. Even if you set a number or bool, like 1 or true as the value of the Environment Variable, it will be considered a string.

Parent processes can’t access Environment Variables exposed by child processes

Parent process(es) can’t access Environment Variables exposed by child processes.

For example, you run a script in your Terminal:

bash my_bash_script.sh

Let’s say this script sets a variable called MY_VAR:

export MY_VAR=the-value`

Once the script is finished, you won’t be able to access MY_VAR in your Terminal. It is only available in the script and in the processes or scripts started by the script.

This means that if you use export MY_VAR=... in a Script Step, MY_VAR won’t be available in subsequent Steps. This is true for other Steps too, regardless of which language the Step is written in.

The Bitrise CLI includes a mechanism for exposing environment variables from Steps so that subsequent Steps can also access it, through the Bitrise CLI tool called envman.

A simple example:

envman add --key MY_TEST_ENV_KEY --value 'test value for test key'

You can find more examples in envman’s README, and in the Expose an Environment Variable and use it in another Step guide.

Availability order of environment variables

Environment Variables are available after the environment variable is processed.

There are Environment Variables exposed by the Bitrise CLI itself. These are available from the start: for example, BITRISE_SOURCE_DIR and BITRISE_TRIGGERED_WORKFLOW_ID.

All other Environment Variables are processed and made available as the build progresses.

The processing order is this:

  1. Environment Variables exposed by the Bitrise CLI.
  2. Secrets and App Env Vars: both are processed before a Workflow starts.
  3. One-off environment variables specified for the build through our API.
  4. Workflow environment variables: when the processing of the specified Workflow starts, the Environment Variables specified for that Workflow are made available.

    If the workflow has workflows chained before or after it, the environment variables of the chained workflows are processed and made available right before the first step of the workflow would run.

  5. Step inputs: they are exposed for each Step, right before the Step would start.
  6. Step outputs: they are exposed by the specific Step, so those are available for subsequent Steps after the Step finishes.

Why does the processing order matter?

An Environment Variable is only available after it is processed and made available. You can only reference/use Environment Variables that are already processed!

Environment variables of chained workflows

Once an Environment Variable of a Workflow is processed and made available, it is available everywhere else during the build. This means that other Workflows of the chain can use the Environment Variables of a Workflow which is performed before the specific Workflow, similar to Step outputs, which are available for every other step after the Step that generates the outputs completes.

You can find more information about Environment Variable availability of Workflow Env Vars in chained Workflows in the Workflows: Note about workflow environment variables documentation.