Skipping a given commit or pull request

Abstract

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).

Exiting a build triggered by a draft PR

When you use the draft PR function of GitHub, Bitrise inserts a Environment Variable 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.

You can spot the GITHUB_PR_IS_DRAFT Env Var in your build and abort the build immediately to save concurrencies/credits in two ways.

If you insert below script command into a Script Step, the command will catch the draft PR Env Var, if it is defined, and the build will fail.

#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x

if [[ -z "${GITHUB_PR_IS_DRAFT}" ]]; then
     echo 'Not a draft PR'
else
     exit 1
fi

If you'd rather run an empty green build super quickly, we recommend that you insert below run_if command to each Step in your Workflow to skip the Steps.

workflow1:
    steps:
    - script@1:
        run_if: '{{enveq "GITHUB_PR_IS_DRAFT" ""}}'   
        inputs:
        - content: |-
            #!/usr/bin/env bash
            # fail if any commands fails
            set -e
            # debug log
            set -x

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.

In this section: