Generic Workflow recipes
Workflow recipes that aren't specific to any platform type (such as iOS, Android, Flutter, and so on) but provide help with the CI/CD process and using Bitrise in general.
Workflow Recipes provide ready-made solutions for common Workflow tasks: a range of different Recipes along with examples of entire Workflows.
Here you can find Workflow recipes that aren't specific to any platform type (such as iOS, Android, Flutter, and so on) but provide help with the CI/CD process and using Bitrise in general.
(iOS/Android) Send build status to Slack
Description
Send a message to Slack with the build status after a build has finished.
Prerequisites
You have set up a Slack webhook and added it to Env Vars (for example, $SLACK_WEBHOOK
). See Configuring Slack integration for details.
Instructions
Add the Send a Slack message Step. Set the input variables:
-
Slack Webhook URL: for example,
$SLACK_WEBHOOK
. -
Target Slack channel, group or username: for example,
#build-notifications
.
Check out other options in the Step documentation or in the Workflow Editor.
bitrise.yml
- slack@3: inputs: - channel: "#build-notifications" - webhook_url: $SLACK_WEBHOOK
Cloning a Git repository
Description
Clone a Git repository.
Instructions
-
Add the Activate SSH key (RSA private key) Step. This allows the Git client on the build VM to access private repositories.
-
Add the Git Clone Repository Step.
Check out other options in the Step documentation or in the Workflow Editor.
bitrise.yml
- activate-ssh-key@4: run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone@6: {}
Example Gitflow release branch Workflow
Description
An example Workflow that creates a Gitflow release branch for a specific version. The version can be passed on as an Environment Variable for the Workflow.
Prerequisites
Make sure that Bitrise has write access to your repository by manually adding an SSH key with write permission on GitHub.
bitrise.yml
# Run the workflow with $VERSION env set up to, for examaple, '2.4.3' create-release-branch: steps: - activate-ssh-key@4: run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone@6: {} - script@1: inputs: - content: |- #!/usr/bin/env bash # fail if any commands fails set -e # debug log set -x git checkout -b release-$VERSION git push origin release-$VERSION
(iOS/Android) Send QR code to Slack
Description
Send a QR code of the iOS or Android build uploaded to bitrise.io to Slack.
Prerequisites
-
You have your iOS or Android app archived.
-
You have set up a Slack webhook and added it to Env Vars (for example,
$SLACK_WEBHOOK
). See Configuring Slack integration for details.
Instructions
-
Add the Deploy to Bitrise.io - Apps, Logs, Artifacts Step.
-
Add the Create install page QR code Step.
-
Add the Send a Slack message Step. Set the input variables:
-
Slack Webhook URL: for example,
$SLACK_WEBHOOK
. -
Target Slack channel, group or username: for example,
#build-notifications
. -
A URL to an image file that will be displayed as a thumbnail:
$BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL
.
-
bitrise.yml
- deploy-to-bitrise-io@2: {} - create-install-page-qr-code@1: {} - slack@3: inputs: - channel: "#build-notifications" - thumb_url: $BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL - webhook_url: $SLACK_WEBHOOK
Start builds from a parent Workflow
Description
Start one or more builds in parallel with specified Workflows from a parent Workflow. You can add a Step to wait for their completion.
Start builds for different apps
Using this method, you can only start builds for the same app. If you would like to start another build for a different app, you can use the Trigger Bitrise workflow Step.
Prerequisites
-
Make sure you have a valid Bitrise API key in your Secrets (
$BITRISE_API_KEY
). See Personal access tokens for more details. -
A Workflow or multiple Workflows you would like to run in parallel (for example,
workflow-1
andworkflow-2
).
Instructions
-
Add a Bitrise Start Build Step. Set the following input variables:
-
Workflows: The Workflow(s) to start. Insert only one Workflow per line.
-
Bitrise Access Token:
$BITRISE_API_KEY
-
-
(Optional) Add any Step you would like to run in parallel while the triggered Workflows are running in the parent Workflow.
-
(Optional) Add a Bitrise Wait for Build Step. Set the Bitrise Access Token input variable:
$BITRISE_API_KEY
bitrise.yml
parent-workflow: steps: - build-router-start@0: inputs: - workflows: |- workflow-1 workflow-2 - access_token: "$BITRISE_API_KEY" - script@1: inputs: - content: echo "Doing something else..." - build-router-wait@0: inputs: - access_token: "$BITRISE_API_KEY"
Optimizing cache efficiency for pull request builds
Description
Bitrise caching is branch-based. You can optimize cache efficiency by keeping the cache up-to-date on a given branch.
If a branch doesn't have a cache entry yet, the repository's default branch is used as a fallback to pull a cache entry. If a pull request targets the main branch, this fallback mechanism is used to pull the default branch's cache (as the pull request branch doesn't have any cache entry yet). This means that caching can still be efficient if the pull request destination is the default branch and the cache is up-to-date on the default branch.
Instructions
-
Make sure that any Workflow that runs frequently on the default branch contains the Bitrise.io Cache:Push Step. This will keep the cache up to date with content from successful builds. We recommend one of two approaches:
-
Run the Workflow after every commit (for example, a merge) to the default branch, triggered by the push event on the default branch.
-
Run the Workflow as a scheduled nightly build every day. This warms up the cache by pushing content based on the latest state of the default branch.
-
-
(Optional) Set the Compress cache input variable to
true
. This can be useful if your cache folders are large and you are experiencing slow build times. -
Make sure that the Workflow which runs the pull requests contains the Bitrise.io Cache:Pull Step.
This pulls the cache from successful builds on the default branch. We don't recommend pushing content into the cache for pull request builds for security and efficiency reasons. Even if the Workflow contains the Bitrise.io Cache:Push Step, it's skipped by default for pull request builds.
bitrise.yml
Workflow running on the default branch:
# Add steps that produce the cached content (e.g. dependecies, builds) - cache-push@2: {}
Pull request Workflow:
- cache-pull@2: {} # Add steps that can utilise the restored cache content
GitHub pull request: send the build QR code
Description
Send a comment to the GitHub pull request with a QR code to the build uploaded to bitrise.io.
Prerequisites
-
You have your iOS or Android app archived.
-
You have a GitHub personal access token with the
repo
scope and you've added it as a Secret ($GITHUB_ACCESS_TOKEN
) to your Bitrise app.
Instructions
-
Add the Deploy to Bitrise.io - Apps, Logs, Artifacts Step.
-
Add the Create install page QR code Step.
-
Add the Comment on GitHub Pull Request Step and set the following input variables:
-
GitHub personal access token: Set it to the previously created Secret,
$GITHUB_ACCESS_TOKEN
. -
Body: Add the following:
![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) $BITRISE_PUBLIC_INSTALL_PAGE_URL
-
bitrise.yml
- deploy-to-bitrise-io@2: {} - create-install-page-qr-code@1: {} - comment-on-github-pull-request@0: inputs: - body: |- ![QR code]($BITRISE_PUBLIC_INSTALL_PAGE_QR_CODE_IMAGE_URL) $BITRISE_PUBLIC_INSTALL_PAGE_URL - personal_access_token: "$GITHUB_ACCESS_TOKEN"