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 ⚓
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 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:
- Activates the SSH key, if one has been added to the app. The step saves it to file and then loads it into the user’s ssh-agent with the
ssh-addcommand. The step, by default, does not run if there is no SSH key added.
- Clones the Git repository of the project with the
Git Clone RepositoryStep.
- Rusn the
Bitrise.io Cache:PushSteps. Read more about caching on Bitrise.
- Deploys build artifacts with the
Deploy to Bitrise.ioStep.
The deploy workflow ⚓
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:
- it has the same ‘basic’ steps
- its specific steps are dependent on the project type
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.
The configuration format of the Bitrise CLI is referred to as bitrise.yml. This is the expected file name the configuration should be saved with.
Creating your own Step is as simple as running a bitrise CLI (v1.6.1+) command and following the guide it prints. You can generate Steps using either the Bash or Go...
The project scanner is a tool that identifies the given project's type and generates a basic Bitrise configuration. Each supported project type has its own scanner: these scanners are stored...