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

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_DEPLOY_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.

$BITRISE_TEST_RESULT_DIR

Each Step has its own value of this variable. It provides a unique subdirectory, under $BITRISE_TEST_DEPLOY_DIR for each Step to save its test results.

$BITRISE_FAILED_STEP_TITLE

The title of the Step that first fails in a build. In other words, the Step that sets the build status to Failed.

$BITRISE_FAILED_STEP_ERROR_MESSAGE

The error message of the Step that first fails in a build.

$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

Description

$BITRISE_BUILD_NUMBER

Build number of the build on bitrise.io.

$BITRISE_APP_TITLE

The title of your project on bitrise.io. You can change it any time on the Project settings page of the project.

$BITRISE_APP_URL

The URL or your project on bitrise.io. This is not the same as the Git repository URL! A project 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 project on bitrise.io. It’s part of the project 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 project. 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 project.

$BITRISEIO_GIT_REPOSITORY_SLUG

The slug of the Git repository of the project.

$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 projects 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 project, a pipe character (|) separates the URLs in the list.

This is only relevant for iOS projects and for cross-platform projects 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 project, a pipe character (|) separates the URLs in the list.

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

$BITRISE_CERTIFICATE_PASSPHRASE

The passphrase you set for the uploaded Apple certificates on the project’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 projects and for cross-platform projects 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.

$BITRISE_TRIGGER_BY

Identifies the entity that triggered the build. The value can be:

  • The Git user's name when the build is triggered by a Git provider.

  • The Bitrise user's name if the build is triggered manually from the Bitrise web UI.

  • The value specified in the triggered_by build parameter if the build is triggered any other way (such as scheduled builds or builds triggered by the API).

$BITRISE_TRIGGER_METHOD

The method by which the build was triggered.

  • schedule: When the build is triggered by a scheduler.

  • webhook: When the build is triggered automatically by a webhook at a Git provider.

  • manual: When the build is triggered by any other trigger, including the API.

$BITRISE_GIT_PULL_REQUEST_COMMENT

The comment message and its corresponding ID from a pull request (or merge request in the case of GitLab).

Only available when the build is triggered by a PR comment: the build trigger must have a pr_comment value.

$BITRISE_GIT_PULL_REQUEST_COMMENT_ID

The comment ID from a pull request. Only available when the build is triggered by a PR comment.

$BITRISE_GIT_PULL_REQUEST_LABELS

A multiline list of new labels added to the pull request along with existing labels. Only available when the build is triggered by adding a label to a pull request or by a PR event with existing labels.

Only supported for GitHub and GitLab.

$BITRISE_GIT_CHANGED_FILES

Lists file paths changed by a code push or pull request. Contains max 3000 files per event. It's available when:

  • A push event triggers a build. Only supported for GitHub and GitLab.

  • A PR event triggers a build and the trigger has a changed_files or commit_message condition. Supported for all three main Git providers.

Note: this env var can become really large in some builds. If you build custom scripts that parse this env var, please see the env var size limitations section below.

$BITRISE_GIT_COMMIT_MESSAGES

The commit messages of a code push or pull request. Contains max the first 2048 commits, and at most 1000 characters in each message. It's available when:

  • A push event triggers the build. Only supported for GitHub and GitLab.

  • A PR event triggers a build and the trigger has a commit_message condition. Supported for all three main Git providers.

Note: this env var can become really large in some builds. If you build custom scripts that parse this env var, please see the env var size limitations section below.

Env Var size limitations

Some of the above environment variables can become really large in some builds (for example, if a git commit has a really long commit message or a pull request modifies thousands of files). If the total size of all env vars would hit OS limits, Bitrise removes some env vars from the runtime environment and writes the full value to a file on disk.

If you have custom scripts that rely on env vars that could grow large in some builds, you should read the value from this env file instead. The env var is located at $BITRISEIO_ENVFILE_PATH on both macOS and Linux stacks. It has the following format:

envs:
  # Every env var from the build trigger and git event.
  BITRISE_GIT_CHANGED_FILES: ...
  BITRISE_GIT_COMMIT_MESSAGES: ...
  CI: true
  PR: true
  [...]

# List of env var KEYS that had to be erased. You should read the original value from the map above, this is just for debugging.
erased_envs:
- BITRISE_GIT_CHANGED_FILES
Table 3. Pipeline Env Vars exposed by bitrise.io

Env Var

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

Description

$RM_RELEASE_ID

The unique identifier of your release on bitrise.io. It’s part of the release URLs, too.

$RM_RELEASE_VERSION

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

$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_CANDIDATE_BUILD_SLUG

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

$RM_CONNECTED_APP_ID

The unique identifier of your connected app on bitrise.io.

$RM_PROJECT_ID

The unique identifier of your project on bitrise.io. It’s part of the project URL, too.

$RM_WORKSPACE_ID

The unique identifier of your workspace on bitrise.io.

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

Env Var

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.