Cancel running/queued builds if a pull request build is triggered

Feature Requests Released
1

Description of the feature request

When a build is triggered by a push to a feature branch and I create a pull request shortly after, it triggers another build for the pull request. Now two builds with the same commit hash are running. It would be nice if it was somehow possible to let the pull request build cancel all queued/running builds that have the same commit hash.

Use case / for what or how I would use it

Currently, we manually cancel running builds for feature branches if we create a pull request shortly after pushing the changes. We would use the requested feature to automate this process.

2

There is a Rolling Builds feature: https://devcenter.bitrise.io/builds/rolling-builds/

3

Thanks for your reply. We actually enabled rolling builds, but it doesn’t seem to work in our specific case, both builds are running. Same branch, same workflow, same commit hash. Can we already configure our build like that? Please see the attached screenshots for the current configuration.

38
381692×574 50 KB

4

This is what currently happens:

53
532406×568 60 KB

5

It seems that you have the same workflow primary set for both pull request and push triggers.
Not sure if this fits your needs but you can disable one of them.
You can do it here:

image
image1294×275 16.8 KB

2 Likes
6

@koral is absolutely right as usual, just wanted to share the related documentation Using the Trigger Map to trigger builds | Bitrise DevCenter :wink:

1 Like
7

Yes exactly, the pull request trigger is active because we want to report the result of the pre-merged build back to the pull request in our GitLab. At the same time, we want to have a build for every push to a feature branch.
Additionally, we want to cancel any running/queued build that was triggered by pushing to a feature branch when a pull request triggers a pre-merged build for the same branch. As far as we understand, this is not possible with the current configuration (probably because the feature branch and the pre-merged feature branch are not the same thing).

However, I think we could define a custom workflow that is triggered by pull requests that uses the Bitrise API to check if there are running/queued builds for the same branch and cancel them before triggering the primary workflow :slight_smile:

8

@stefan.engel do you only want to cancel those builds? We have a .yml script that might be able to help you cancel builds, although I’m not entirely sure it’d fit your use case, but you can give it a try:

  - script@1.1.5:
inputs:
- content: |
#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x

brew install jq
# First request: get the 10 latest builds and store them in the json variable
json=$(curl -H 'Authorization: '$API_TOKEN'' 'https://api.bitrise.io/v0.1/apps/'$BITRISE_APP_SLUG'/builds?limit=10')

# Second request: use jq to filter the previous json response to builds that have larger buildnumber than
 current one and status is 0 (this means on-hold or running builds) and store the slugs in the ABORT_SLUG variable
ABORT_SLUG=$(echo "${json}" | jq -r '.data[] | select(.build_number>'$BITRISE_BUILD_NUMBER') |
 select(.status==0) | .slug')
echo "------------------"
echo "Build slugs to abort:"
echo "$ABORT_SLUG"
echo "------------------"# while loop to go through all the slugs that are stored in ABORT_SLUG separated by a linebreak and call the abort endpoint of each build.
while read -r slug; do
json=$(curl -X POST -H 'Authorization: '$API_TOKEN''
 'https://api.bitrise.io/v0.1/apps/'$BITRISE_APP_SLUG'/builds/'$slug'/abort' -d '{"abort_reason": "abort with abort_with_success=true test & skip_notifications=true", "abort_with_success": true,"skip_notifications": true}')
done <<< "$ABORT_SLUG"
echo "------------------"
title: Abort all previous builds
1 Like
9

Yes, we just want to cancel them :slight_smile:

Our current script looks like this:

    local BITRISE_BASE_URL='https://api.bitrise.io/v0.1/apps'

for BUILD in $(curl -H "Authorization: $BITRISE_AUTH_TOKEN" $BITRISE_BASE_URL/"$BITRISE_APP_SLUG"/builds\?status=0\&branch="$BRANCH_NAME" | jq '.data[] | .slug'); do
    BUILD_SLUG="${BUILD%\"}"
    BUILD_SLUG="${BUILD_SLUG#\"}"

    if [ "$BUILD_SLUG" = "$BITRISE_BUILD_SLUG" ] ; then
        echo "Found current build: $BITRISE_BUILD_SLUG"
    else
        echo "Found already running build $BITRISE_BUILD_SLUG, cancelling..."
        curl -X POST -H "Authorization: $BITRISE_AUTH_TOKEN" $BITRISE_BASE_URL/"$BITRISE_APP_SLUG"/builds/"$BUILD_SLUG"/abort -d '{"abort_reason": "Aborted by a merge request"}'
    fi
done

We use it in the workflow triggered by merge requests and it seems to do the job. The only downside is that it cannot cancel running builds as long as the merge request build job itself is waiting in the queue.

1 Like