Default Pipelines and Workflows

Abstract

When you add a new project on bitrise.io, one or two Workflows are created automatically, depending on your project.

When you add a new project on bitrise.io, we create initial Pipelines and Workflows for you. These are called default Pipelines and Workflows. A default Pipeline consists of default Workflows.

You can use these to run your tests or create installable binaries such as IPAs or APKs. Feel free to modify the default Pipelines and Workflows to suit your needs.

Default Pipelines

Default Pipelines are created for all new iOS and Android projects. These Pipelines consist of automatically created default Workflows.

Table 1. Default Pipelines for iOS

Pipeline ID	Pipeline summary	Workflows within the Pipeline
`run_tests`	Builds your iOS project, runs your Xcode tests in two parallel shards. The number of shards is specified in the env var `$TEST_SHARD_COUNT`.	`build_for_testing` `test_without_building`

Pipeline ID

Pipeline summary

Workflows within the Pipeline

run_tests

Builds your iOS project, runs your Xcode tests in two parallel shards. The number of shards is specified in the env var $TEST_SHARD_COUNT.

build_for_testing

test_without_building

Table 2. Default Pipelines for Android

Pipeline ID	Pipeline summary	Workflows within the Pipeline
`run_tests`	Run your Android instrumented tests in two parallel test shards and get a test report. The number of shards is specified in the env var `$TEST_SHARD_COUNT`.	`run_instrumented_tests`

Default Workflows for an iOS project

For a new iOS project, Bitrise automatically generates several Workflows. You can customize these Workflows or create new ones based on them.

Table 1. Default iOS Workflows

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your project’s tests.	The Workflow clones your Git repository, installs Node Version Manager (NVM) and select the Node version, restores cached `node_modules` dependencies, runs your tests using the package manager appropriate to your project and saves the cache.
`build_for_testing`	Builds your Xcode project ready for testing.	The Workflow clones your Git repository, builds your app ready for testing, apportions tests into each test shard and deploys the app plus tests to Bitrise so they can be used in subsequent Workflows. This Workflow is part of a default Pipeline.
`test_without_building`	Tests your iOS app without needing to rebuild it.	Retrieves the app and tests from the preceding Workflow in a Pipeline and tests compiled bundles using Xcode’s `test_without_building` command. This Workflow is part of a default Pipeline.
`archive_and_export_app`	Run your Xcode tests and create an IPA file to install your app on a device or share it with your team.	The Workflow clones your Git repository, caches and installs your project’s dependencies if there are any, runs your Xcode tests, and exports an IPA file from the project.
`build`	Builds your Xcode project. Tests not found This Workflow is generated only if the project scanner didn't find any tests configured in your Xcode project.	The Workflow clones your Git repository, caches and installs your project’s dependencies if there are any, and builds your project. It uses Xcode's build for testing action.

Default Workflows for an Android project

For a new Android project, Bitrise automatically generates three new Workflows. You can customize these Workflows or create new ones based on them.

Table 1. Default Android Workflows

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your Android unit tests and get the test report.	The Workflow clones your Git repository, caches your Gradle dependencies, installs Android tools, runs your Android unit tests and saves the test report.
`build_apk`	Run your Android unit tests and create an APK file to install your app on a device or share it with your team.	The Workflow clones your Git repository, installs Android tools, sets the project’s version code based on the build number, runs Android lint and unit tests, builds the project’s APK file and save it.
`run_instrumented_tests`	Run your Android instrumented tests with test sharding and get a test report.	The Workflow clones your Git repository, caches your Gradle dependencies, installs Android tools, boots up an Android emulator to run your Android instrumented tests and saves the test report. This Workflow is part of a default Pipeline which utilizes parallelism: it runs multiple copies of the Workflow to shard instrumented tests.

Workflow ID

Workflow summary

Workflow description

run_tests

Run your Android unit tests and get the test report.

The Workflow clones your Git repository, caches your Gradle dependencies, installs Android tools, runs your Android unit tests and saves the test report.

build_apk

Run your Android unit tests and create an APK file to install your app on a device or share it with your team.

The Workflow clones your Git repository, installs Android tools, sets the project’s version code based on the build number, runs Android lint and unit tests, builds the project’s APK file and save it.

run_instrumented_tests

Run your Android instrumented tests with test sharding and get a test report.

The Workflow clones your Git repository, caches your Gradle dependencies, installs Android tools, boots up an Android emulator to run your Android instrumented tests and saves the test report.

This Workflow is part of a default Pipeline which utilizes parallelism: it runs multiple copies of the Workflow to shard instrumented tests.

Default Workflows for a Node.js project

Bitrise generates one default Workflow for a Node.js project: a Workflow to run your project's lint and test scripts. You can customize this Workflow or create new ones based on it.

Table 1. Default Workflows for Node.js

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your project’s tests.	The Workflow clones your Git repository, selects and installs the Node version, installs the `npm` packages, and, depending on the available scripts in your `package.json` file, runs the lint and test scripts. The Workflow also supports `node_modules` caching for better performance.

Default Workflows for a Kotlin Multiplatform project

Bitrise generates one default Workflow for a Kotlin Multiplatform project: it contains the Gradle Unit Test Step to run the test Gradle task. You can customize this Workflow or create new ones based on it.

Table 1. Default Workflows for Kotlin Multiplatform

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your project’s tests.	The Workflow clones your Git repository, and runs the `test` Gradle task using the Gradle Unit Test Step.

Default Workflows for a Java project

The project scanner can detect Java projects and create default Workflows for them. A new project is considered a generic Java project if:

It uses Gradle (the code contains the usual Gradle configuration files and a Gradle Wrapper script in the project root directory) and it doesn't use Android or Kotlin Multiplatform required dependencies.
It uses Maven with a POM.xml project configuration file in the root directory, and has a Maven Wrapper script.

For a generic Java project, Bitrise generates default Workflows based on the build tool.

Table 1. Default Workflows for a Java project using Gradle

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your projects tests.	The Workflow clones your Git repository and runs tests by using the Gradle Unit Test Step which runs the `test` Gradle task.

Table 2. Default Workflows for a Java project using Maven

Workflow ID	Workflow summary	Workflow description
`run_tests`	Run your projects tests.	The Workflow clones your Git repository and runs tests by using a Script step, running the Maven Wrapper’s test command: `./mvnw test`.

Default Workflows for multiplatform projects

For multiplatform projects - projects that aren't native iOS or Android mobile apps but created with some mobile development framework, such as React Native, Flutter, Ionic or Cordova -, Bitrise creates two default Workflows: primary and deploy.

The exact Steps included in these default Workflows depend on the project type. However, the main goals of the two Workflows are the same, regardless of project type:

The primary Workflow clones your project's repository, installs and caches your dependencies, and runs any tests configured in the project.
The deploy Workflow, in addition to installing and caching dependencies and running tests, also builds your project: it tries to generate an APK or IPA file.

For more details about what the default Workflows include for different project types, try out our demo apps!

In this section: