Skip to main content

Builds

Abstract

A Bitrise build is specified by the app’s Workflow which is a collection of Steps. The app’s build configuration can be modified in the bitrise.yml file or in the graphical Workflow Editor.

A Bitrise build is a series of jobs, specified by the app’s Workflow which is a collection of Steps. The app’s build configuration is specified in the bitrise.yml configuration file which you can modify in bitrise.io’s graphical Workflow Editor or locally. The file can be stored on bitrise.io or in your app's Git repository.

When a build is running, the scripts that define the Steps will be executed in the order you’ve defined in your Workflow, with the input parameters you set. They can produce multiple different outputs that other Steps can use, including but not limited to executable binaries, screenshots, test reports, variables, and so on.

The build process is the following:

  1. Starting the build, either manually or by an automatic trigger.

  2. Environment preparation: A virtual machine will be provisioned and prepared to run the build. Build specific Environment Variables are preset so you can use these in your Steps. You can find more information about the available stacks in the Workflow Editor, on the Stack tab.

  3. Workflow execution: Steps in Workflows are executed in the same order as defined in the Workflow Editor of your application, from top to bottom. You can reorder the Steps by dragging them around. The log each Step generates will be displayed on the build’s details page.

  4. Cleanup: After the execution of the build, a build log is created and stored on the Bitrise server. The virtual machine running the build is destroyed so your code/files will never fall into the wrong hands.

    Build retention for 200 days

    On the Builds page of your app, we only show builds from the last 200 days. The same limit applies if you are searching for specific builds on the page. This limitation also applies to most API calls: the GET/apps/{app-slug}/builds endpoint and related endpoints can only return builds from the last 200 days.

    However, there are two methods to get a build that is older than 200 days:

After the build has finished, users can be notified via email, or you can set up your own Slack integration, for example.