GitHub

Default workflows

When you add a new app on bitrise.io, one or two workflows are created automatically, depending on your app. These are the primary and the deploy workflows. By default, every code change in your project’s repository triggers the primary workflow if the required webhook has been set up.

Triggers can be configured so that any other workflow (including deploy) is automatically triggered when certain code events happen. For more information, read some more about build triggers.

The primary workflow

The primary workflow is automatically created when adding a new app. Once the process of adding the app is over, Bitrise triggers the app’s first build automatically: this build runs with the primary workflow.

The primary workflow is not the same for every app you create: it contains different Steps depending on the project type. For example, an Android project’s primary workflow will include the Install missing Android SDK components, the Android Lint and the Android Unit Test Steps. But overall, primary is a “basic” workflow that always performs the following actions:

The deploy workflow

The deploy workflow is automatically created when adding a new app if you have tests configured in your app. It is similar to the primary workflow in a number of ways:

The deploy workflow, however, also contains the Steps that “build” the project, and, if the build is successful, produces the necessary artifacts for installing the app or deploying it online. For example, an Android project’s deploy workflow contains the Android Build Step that builds your project with Gradle, and the Android Sign Step that creates a signed .apk file which can be deployed to Google Play or installed on test devices.