Skip to main content

Available Environment Variables

Abstract

Environment Variables (Env Vars) consist of a key and a value, as well as optional attributes. They can be defined on the level of apps, Workflows or Steps.

Environment Variables (Env Vars) consist of a key and a value. They can also include optional attributes. They can be defined on the level of apps, Workflows or Steps.

You can set your own Env Vars but there is a selection of Env Vars that are exposed automatically by either the Bitrise CLI or bitrise.io.

In addition, plenty of Bitrise Steps export output variables. These variables are available to subsequent Steps during a build. You can find them in the Step configuration of each Step:

  • In the Workflow Editor, you can check them in the Output properties section of a Step.

  • In the step.yml of a Step, you can find them under outputs.

Release Management also passes a number of Env Vars to Bitrise builds: Table 4, “Environment Variables passed to the builds from Release Management”.

Environment Variables have a set availability order. This is the order in which they are made available as a build progresses: Availability order of Environment Variables.

Step outputs exposed as Env Vars

Steps can also expose Step outputs as Env Vars. For example, a Step that builds a binary can expose that binary to other Steps as an Env Var. As basically any Bitrise Step can expose outputs this way, we won't list them all but you can find all Environment Variables related to the git cloning process: Table 5, “Env Vars exposed by the Git Clone Repository Step”.

Table 1. Env Vars exposed by the Bitrise CLI

Env Var key

Description

$BITRISE_TRIGGERED_WORKFLOW_ID

The ID of the Workflow that was triggered. This Env Var is exposed regardless of whether the Workflow was triggered manually or automatically.

$BITRISE_TRIGGERED_WORKFLOW_TITLE

The title of the Workflow that was triggered. This Env Var is exposed regardless of whether the Workflow was triggered manually or automatically.

$BITRISE_BUILD_STATUS

The current status of the build. The available options are:

  • 0: Successful.

  • 1: Failed.

A successful current status means that none of the previous Steps in the build failed.

$BITRISE_SOURCE_DIR

Path to the base working directory. By default, it’s the directory where Bitrise runs, unless you provide a different value. This can be overwritten during the build, which will change the working directory for subsequent Steps in the build.

$BITRISE_DEPLOY_DIR

Path to the directory that stores artifacts and files for deployment. It’s a temporary directory created by the Bitrise CLI by default, and can be overwritten before starting the Bitrise CLI. The Deploy to Bitrise.io Step looks for your build artifacts - such as an IPA or APK of the app -, test results, and other files in this directory.

$BITRISE_TEST_RESULT_DIR

Root directory for all test results created by the Bitrise CLI. Test results placed in this directory can be accessed in the Test Reports add-on.

$CI

Indicates whether the Bitrise CLI is running in Continuous Integration mode. The possible values are:

  • true

  • false

$PR

Indicates whether the Bitrise CLI is running in PR (Pull Request) mode. Running in Pull Request mode means that Bitrise builds your code in the state as if the Pull Request was already merged. The possible values are:

  • true

  • false

Table 2. Env Vars exposed by bitrise.io

Env Var key

Description

$BITRISE_BUILD_NUMBER

Build number of the build on bitrise.io.

$BITRISE_APP_TITLE

The title of your app on bitrise.io. You can change it any time on the Settings tab of the app.

$BITRISE_APP_URL

The URL or your app on bitrise.io. This is not the same as the git repository URL! An app URL has the following format:

app.bitrise.io/APP-SLUG/

For example: https://app.bitrise.io/app/31e481ce08e0xfd9.

$BITRISE_APP_SLUG

The slug that uniquely identifies your app on bitrise.io. It’s part of the app URL, too.

$BITRISE_BUILD_URL

The URL of the build on bitrise.io.

$BITRISE_BUILD_SLUG

The slug that uniquely identifies a build on bitrise.io. It’s part of the build URL, too.

For example, let’s take a look at this build URL: https://app.bitrise.io/build/d75abbebxfc9ca4e. The build slug is d65abbebxfc9ca4e in this example.

$BITRISE_BUILD_TRIGGER_TIMESTAMP

The date and time when the build was triggered.

$GIT_REPOSITORY_URL

The URL of the Git repository that hosts your app. This can be changed in the Settings tab of the app. It can be in either SSH or HTTPS format.

$BITRISE_GIT_BRANCH

The git branch that is built by Bitrise. For example, main.

$BITRISEIO_GIT_BRANCH_DEST

Used only with builds triggered by pull requests: the destination/target branch of the pull request that triggered the build.

For example, a pull request wants to merge the content of a branch into the branch main. In this case, this Env Var’s value is main.

$BITRISE_GIT_TAG

If a build is triggered by a Git Tag, this Env Var stores the tag used.

$BITRISE_GIT_COMMIT

The commit hash of the Git commit that triggered the build, when applicable.

$BITRISE_GIT_MESSAGE

The commit message, pull request title, or the message you specified if you triggered the build manually.

$BITRISEIO_GIT_REPOSITORY_OWNER

The owner of the Git repository of the app.

$BITRISEIO_GIT_REPOSITORY_SLUG

The slug of the Git repository of the app.

$BITRISE_PULL_REQUEST

The ID of the pull request that triggered a build.

$BITRISEIO_PULL_REQUEST_REPOSITORY_URL

The URL of the repository from where the pull request that triggered a build has been sent.

$BITRISEIO_PULL_REQUEST_MERGE_BRANCH

The pre-merge branch - if the Git hosting provider supports and provides the pre-merged state of a pull request on a special merge branch.

$BITRISEIO_PULL_REQUEST_HEAD_BRANCH

The pull request head branch, if the Git hosting provider system supports and provides this. This special git ref should point to the source of the pull request.

$GITHUB_PR_IS_DRAFT

For apps hosted on GitHub only: it is set to true if the build is triggered by a draft pull request.

$BITRISE_PROVISION_URL

The URL of the Apple provisioning profiles uploaded to bitrise.io. If there is more than one provisioning profile uploaded for your app, a pipe character (|) separates the URLs in the list.

This is only relevant for iOS apps and for cross-platform apps with iOS versions.

$BITRISE_CERTIFICATE_URL

The URL of the Apple certificates uploaded to bitrise.io. If there is more than one certificate uploaded for your app, a pipe character (|) separates the URLs in the list.

This is only relevant for iOS apps and for cross-platform apps with iOS versions.

$BITRISE_CERTIFICATE_PASSPHRASE

The passphrase you set for the uploaded Apple certificates on the app’s Code Signing & Files tab. If there is more than one certificate with a passphrase, a pipe character (|) separates the phrases in the list.

This is only relevant for iOS apps and for cross-platform apps with iOS versions.

$BITRISE_IO

Indicates that the build is running in a bitrise.io environment. Value is set to true by Bitrise when it starts a build.

Table 3. Pipeline Env Vars exposed by bitrise.io

Env Var key

Description

$BITRISEIO_PIPELINE_ID

The ID of the running Pipeline build. This Env Var is exposed regardless of whether the Pipeline was triggered manually or automatically.

$BITRISEIO_PIPELINE_TITLE

The name of the running Pipeline build. This Env Var is exposed regardless of whether the Pipeline was triggered manually or automatically.

$BITRISEIO_FINISHED_STAGES

The status of previously finished Stages and Workflows in a build. Please note that the value of this Env Var may change in the future!

$BITRISEIO_PIPELINE_BUILD_STATUS

The current status of the Pipeline build. The value of this Env Var can be: succeeded, succeeded_with_abort, failed, and aborted. While the Pipeline is running, the Env Var's status is based on the previously finished Stages.

$BITRISEIO_PIPELINE_BUILD_URL

The URL of the Pipeline build.

Table 4. Environment Variables passed to the builds from Release Management

Env Var key

Description

RM_RELEASE_CANDIDATE_VERSION

The version of the binary (APK/AAB or IPA file) generated by the release candidate build.

RM_RELEASE_CANDIDATE_DOWNLOAD_URL

The download URL of the binary (APK/AAB or IPA file) generated by the release candidate build.

RM_RELEASE_CANDIDATE_SLUG

Unique identifier of the binary (APK/AAB or IPA file) generated by the release candidate build.

RM_RELEASE_VERSION

The release name (for Google Play releases) or version (for App Store releases) in Release Management.

RM_RELEASE_CANDIDATE_BUILD_SLUG

The build slug of the build that was selected as a release candidate for the release.

Table 5. Env Vars exposed by the Git Clone Repository Step

Env Var key

Description

$GIT_CLONE_COMMIT_HASH

The hash of the commit that the build uses (the cloned commit).

$GIT_CLONE_COMMIT_MESSAGE_SUBJECT

The subject of the commit message of the cloned commit.

$GIT_CLONE_COMMIT_MESSAGE_BODY

The body (content) of the commit message of the cloned commit.

$GIT_CLONE_COMMIT_COUNT

The commit count of the cloned commit. This Env Var is influenced by the clone_depth Step input. For more information, check out the Git Clone Step description.

$GIT_CLONE_COMMIT_AUTHOR_NAME

The name of the author of the cloned commit.

$GIT_CLONE_COMMIT_AUTHOR_EMAIL

The email of the author of the cloned commit.

$GIT_CLONE_COMMIT_COMMITER_NAME

The name of the committer of the cloned commit.

$GIT_CLONE_COMMIT_COMMITER_EMAIL

The email of the committer of the cloned commit.

In this section:
apps

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

A trigger or build trigger is a configuration for automatically launching a Bitrise build when a specified event happens. Triggers require a webhook set up at your Git hosting provider.