bitrise

The title of the project.

A short summary of the project.

A detailed description of the project.

The name that will appear on the status report sent to connected services (like GitHub, GitLab, Bitbucket, etc.) after the build is finished.

A list of Environment Variables.

The version of the Bitrise configuration format. The Bitrise CLI checks it to ensure compatibility between the configuration file and the CLI version. This is relevant for locally run builds: on the Bitrise website, the CLI is always up to date, so the format_version property doesn't have an effect on builds triggered.

The default Step library for the Steps used in your configuration. Bitrise uses this source if no specific source is provided for a given Step.

The type of your Bitrise project, such as ios, android, flutter, and so on.

The title of the Bitrise configuration.

A short summary of the Bitrise configuration.

A detailed description of the Bitrise configuration.

Docker container definitions used by Steps as service containers.

Docker container definitions used by Steps as execution containers.

Stores project metadata key-value pairs related to the Bitrise configuration. Most importantly, it defines the default stack and the build machine type for the project.

Defines the build triggers on a project level. This is the legacy method of configuring triggers: we recommend using target-based triggers defined as part of a Pipeline or a Workflow instead.

Define Pipelines in your project's configuration. Pipelines can be used to organize the entire CI/CD process and to set up advanced configurations with multiple different tasks running parallel and/or sequentially.

Defines Stages in your configuration. A Stage is a collection of Workflows that are executed sequentially as part of a Pipeline.

The Workflows included in your configuration. A Workflow is a collection of Steps: reusable, configurable units of work. Steps are executed sequentially within a Workflow.

Step bundles allow you to group multiple Steps into a single unit. With Step bundles, you can reuse Steps and sequences of Steps.

Mapping of tool IDs to versions to set up. Version syntax supports exact versions (e.g. '1.2.3'), partial matches to the latest release (e.g. '22:latest'), partial matches to installed versions (e.g. '1.2:installed'), as well as the special aliases 'latest' and 'installed' to select the highest respective version.

The include property allows you to use other configuration YAML files in your Bitrise configuration, to break down large, complex YAML files into smaller, modular components.

The Docker image for the container, in [REPOSITORY[:TAG]] format.

The type of the container. Use execution for containers that execute Steps, and service for background service containers.

Port mappings that expose container ports to the host or to other containers.

A list of Environment Variables.

Additional options passed to the docker create command. Note: --network, --volume (-v), and --entrypoint are not supported.

If true, the current container instance is discarded and a fresh one is started for this Step.

The username used for the docker login command.

The password used for the docker login command. Use a Secret environment variable to avoid exposing the value in the configuration.

The server used for the docker login command. Optional if the server is already part of the image reference.

The title of the Pipeline.

A short summary of the Pipeline.

A detailed description of the Pipeline.

The name that will appear on the status report sent to connected services (like GitHub, GitLab, Bitbucket, etc.) after the build is finished.

The list of Stages that are part of the Pipeline configuration.

The Workflows that are part of the Pipeline configuration. You can create dependencies between Workflows with the depends_on property.

Build priority determines a build's position in the build queue. A build with a higher priority is executed sooner than a build with a lower priority. You can set priorities for Pipelines, Workflows, build triggers, and when manually starting a new build.

This property defines the Workflows that this Workflow depends on. If any of the Workflows in the list fails, this Workflow won't run.

When this property is true, the Pipeline and any other running Workflows are aborted if this Workflow fails.

This property defines whether a Workflow should run if a previous Workflow failed. Set to workflow if you want this Workflow to always run regardless of failures. The default value is none.

The conditions defined for running a Workflow.

The parallel property allows you to run copies of the same Workflow in parallel, in a single instruction. This is particularly useful for test sharding. It takes an integer or an Environment Variable.

A list of Environment Variables.

A Go template expression that defines the conditions for running the Workflow.

The title of the Stage.

A short summary of the Stage.

A detailed description of the Stage.

When this property is true, the Pipeline and any other running Stages are aborted if this Stage fails.

When this property is true, the Stage will always run, even if a previous Stage in the Pipeline failed.

The list of Workflows that are part of the Stage configuration.

Tool provider to use for setup. Defaults to 'asdf' if not specified.

Additional tool plugins beyond Bitrise's vetted and tested integrations for common tools. Maps tool IDs to asdf plugin repository URLs.

The property determines whether a defined trigger is active. The default value is true. If you want to disable the trigger, set it to false.

Code push triggers: they define the conditions for triggering a Bitrise build when code is pushed to the project's repository.

Pull request triggers: they define the conditions for triggering a Bitrise build when a pull request is opened in the project's repository.

Git tag triggers: they define the conditions for triggering a Bitrise build when a Git tag is pushed to the project's repository.

A glob pattern used to match against the condition.

A regular expression pattern used to match against the condition.

Defines whether Bitrise should evaluate every commit message or changed file in a code push or only those belonging to the most recent commit. Its default value is false.

If this property is true, the push trigger is active and can trigger Bitrise builds.

Build priority determines a build's position in the build queue. A build with a higher priority is executed sooner than a build with a lower priority. You can set priorities for Pipelines, Workflows, build triggers, and when manually starting a new build.

A branch of the project's repository. Bitrise triggers a build if code is pushed to the branch defined in this property.

Define a Git commit message that should trigger a Bitrise build.

Set a filepath or a folder. If any file or files change in that location, Bitrise triggers a build.

If this property is true, the pull request trigger is active and can trigger Bitrise builds.

Build priority determines a build's position in the build queue. A build with a higher priority is executed sooner than a build with a lower priority. You can set priorities for Pipelines, Workflows, build triggers, and when manually starting a new build.

If this property is true, draft pull requests can trigger builds, too.

Bitrise triggers a build if the branch name in this property matches the source branch of a pull request opened in the project's repository.

Bitrise triggers a build if the branch name in the property matches the target branch of a pull request opened in the project's repository.

If a pull request's label matches the label in this property, Bitrise triggers a build.

This property looks for comments on pull requests to trigger Bitrise builds.

Define a Git commit message that should trigger a Bitrise build.

Set a filepath or a folder. If any file or files change in that location in a pull request, Bitrise triggers a build.

If this property is true, the tag trigger is active and can trigger Bitrise builds.

Build priority determines a build's position in the build queue. A build with a higher priority is executed sooner than a build with a lower priority. You can set priorities for Pipelines, Workflows, build triggers, and when manually starting a new build.

This property looks for the name of a Git tag to trigger a Bitrise build.

A glob pattern used to match against the condition.

A regular expression pattern used to match against the condition.

The type of the code event the trigger looks for.

If this property is true, the trigger is active and can trigger Bitrise builds.

The name of the Pipeline that will be triggered if the code event matches the trigger condition.

The name of the Workflow that will be triggered if the code event matches the trigger condition.

A branch of the project's repository. Bitrise triggers a build if code is pushed to the branch defined in this property.

Define a Git commit message that should trigger a Bitrise build.

Set a filepath or a folder. If any file or files change in that location, Bitrise triggers a build.

Bitrise triggers a build if the branch name in this property matches the source branch of a pull request opened in the project's repository.

Bitrise triggers a build if the branch name in the property matches the target branch of a pull request opened in the project's repository.

If this property is true, draft pull requests can trigger builds, too.

You can mark pull requests with labels. If a pull request's label matches the label in this property, Bitrise triggers a build.

This property looks for comments on pull requests to trigger Bitrise builds.

Bitrise triggers a build when a Git tag matching the tag defined in this property is pushed to the project's repository.

A pattern used to match against specific code event attributes.

If this property is true, pull requests are allowed to trigger Bitrise builds.

The list of Steps to be executed within the specified container environment.

The name of the container that will be used as the execution environment.

The name of the service container that will be used to run services.

A Go template expression that defines the conditions for running the Workflow within the Stage.

The title of the Workflow.

A short summary of the Workflow.

A detailed description of the Workflow.

The name that will appear on the status report sent to connected services (like GitHub, GitLab, Bitbucket, etc.) after the build is finished.

The Workflows that will run before this Workflow starts.

The Workflows that will run after this Workflow is successfully finished.

A list of Environment Variables.

The list of Steps in the Workflow.

Build priority determines a build's position in the build queue. A build with a higher priority is executed sooner than a build with a lower priority. You can set priorities for Pipelines, Workflows, build triggers, and when manually starting a new build.

Mapping of tool IDs to versions to set up. Version syntax supports exact versions (e.g. '1.2.3'), partial matches to the latest release (e.g. '22:latest'), partial matches to installed versions (e.g. '1.2:installed'), as well as the special aliases 'latest' and 'installed' to select the highest respective version.

Stores project metadata key-value pairs. Most importantly, it defines the stack and the machine type for the Workflow.

The title of the Step bundle.

A short summary of the Step bundle.

A detailed description of the Step bundle.

A list of Environment Variables.

A list of Environment Variables.

A reference to a container. Can be specified as a container ID string or as an object with the container ID as the key and optional configuration as the value.

The default service containers for Steps in this bundle. Service containers accumulate additively through the hierarchy.

The Steps included in the Step bundle.

A list of Environment Variables.

A list of Environment Variables.

A reference to a container. Can be specified as a container ID string or as an object with the container ID as the key and optional configuration as the value.

Overrides the service containers for this bundle invocation.

The file path of the included configuration file. This path is relative to the root of the repository.

The name of the repository that contains the included configuration file. You do not need the URL, just the name. Leave it empty if the file is in the same repository as your current configuration file.

The repository branch that contains the included configuration file. It has a lower priority than tag and commit.

The commit hash of the commit that contains the included configuration file. It takes priority over branch and tag if they are all specified.

The Git tag of the commit that contains the included configuration file. It has a higher priority than branch but a lower priority than commit.