Skipping a given commit or pull request
Depending on your settings, every code change in your repository can trigger Bitrise builds. However, if you need to, you can skip a specific commit or pull request.
Depending on your settings, every code change in your repository can trigger Bitrise builds. However, if you need to, you can skip a specific commit or pull request. Skipping means, in this context, that a code change will NOT trigger a build on Bitrise, even if the triggers are set up to do so.
Preventing a commit from triggering a build
To make sure a specific commit does not trigger a build, include either [skip ci] or [ci skip] in the commit message:
This is not important, please [skip ci]
Or:
I just changed the README [ci skip]
Only the head/last commit message is checked!
If you push more than one commit, only the last (head) commit’s message will be checked for the skip ci pattern!
If you do want to start a build after all, you have two choices:
-
Rebase the commit (change the commit message).
-
Push another commit.
Pushing an empty commit
Git allows to create and push empty commits. If you want to build a skipped build you can do git commit --allow-empty -m "I decided to run this" on the related branch and push the commit.
Preventing a pull request from triggering a build
Pull requests are treated as (virtual) commits themselves, where the commit message is the title + description of the pull request. It is not the commit messages of the individual commits that make up the pull request.
To skip a pull request include the [skip ci] pattern in the pull request’s title or its description.
Individual commit messages are not checked
Putting the [skip ci] pattern in the commit message of individual commits that make up the pull request will not work: the pull request will trigger a build if the appropriate trigger is set up.
Once you decide to not to skip the pull request, you can simply remove the [skip ci] pattern from the pull request’s title or description. This should automatically trigger a new build with the latest commit, and all future commits of the pull request will be built too (unless you add a [skip ci] pattern again).
Skipping Steps triggered by a draft PR
When you use the draft PR function of GitHub, Bitrise inserts an Environment Variable called GITHUB_PR_IS_DRAFT into the build Environment Variable list. If this Env Var is available in your build Env Var list, its value is always set to true.
Triggering builds from draft PRs
You can also configure your trigger map to avoid triggering builds from draft pull requests (or merge requests in the case of GitLab). This doesn't require the GITHUB_PR_IS_DRAFT Env Var: you just need to toggle a switch in the Workflow Editor.
You can use the GITHUB_PR_IS_DRAFT Env Var in your build as part of a conditional: for example, you can skip certain Steps in builds that are triggered by draft PRs:
workflow1:
steps:
- script:
run_if: '{{enveq "GITHUB_PR_IS_DRAFT" ""}}'
inputs:
- content: |-
#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x
In this example, the run_if condition means that the Step will only run if the build is NOT triggered by a draft PR.
Yo recommend that you insert below run_if command to each Step in your Workflow to skip the Steps.
Starting a new build after a draft PR
If you have previously used the draft PR on a build but now you are ready to merge changes to your code from the same PR, clicking the Ready for review button on GitHub won’t trigger a new build on Bitrise. The previous builds will also contain the draft PR related Env Vars. In this case, we recommend you manually start a brand new build from the website or trigger the CI with a new commit.