# Cancel running/queued builds if a pull request build is triggered **URL:** \ **Category:** Released\ **Created:** [July 18, 2019, 8:12am UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663 "2019-07-18T08:12:15Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![stefan.engel](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@stefan.engel](https://discuss.bitrise.io/u/stefan.engel)\ **Post date:** [July 18, 2019, 8:12am UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/1 "2019-07-18T08:12:15Z")
## 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. ---
**Author:** ![koral](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/koral/32/357_2.png) [@koral](https://discuss.bitrise.io/u/koral)\ **Post date:** [July 18, 2019, 3:27pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/2 "2019-07-18T15:27:19Z")
There is a Rolling Builds feature: [https://devcenter.bitrise.io/builds/rolling-builds/](https://devcenter.bitrise.io/builds/rolling-builds/) ---
**Author:** ![stefan.engel](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@stefan.engel](https://discuss.bitrise.io/u/stefan.engel)\ **Post date:** [July 18, 2019, 3:47pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/3 "2019-07-18T15:47:30Z")
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](https://us1.discourse-cdn.com/flex016/uploads/bitrise/original/2X/0/03ab6b48a061588e88c0472d0337dd4359b297ff.png) ---
**Author:** ![stefan.engel](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@stefan.engel](https://discuss.bitrise.io/u/stefan.engel)\ **Post date:** [July 18, 2019, 3:48pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/4 "2019-07-18T15:48:28Z")
This is what currently happens: ![53](https://us1.discourse-cdn.com/flex016/uploads/bitrise/original/2X/b/b7c2e2fb37b525a2f68ae2dc184939792e2737c0.png) ---
**Author:** ![koral](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/koral/32/357_2.png) [@koral](https://discuss.bitrise.io/u/koral)\ **Post date:** [July 18, 2019, 6:28pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/5 "2019-07-18T18:28:11Z")
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](https://us1.discourse-cdn.com/flex016/uploads/bitrise/original/2X/1/1b383df315fd46cd48bff74bfcc60caa880ad8ff.png) ---
**Author:** ![viktorbenei](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/viktorbenei/32/18_2.png) [@viktorbenei](https://discuss.bitrise.io/u/viktorbenei)\ **Post date:** [July 19, 2019, 5:52pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/6 "2019-07-19T17:52:09Z")
@koral is absolutely right as usual, just wanted to share the related documentation [Using the Trigger Map to trigger builds | Bitrise DevCenter](https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-from-the-same-repository) ๐Ÿ˜‰ ---
**Author:** ![stefan.engel](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@stefan.engel](https://discuss.bitrise.io/u/stefan.engel)\ **Post date:** [July 19, 2019, 8:36pm UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/7 "2019-07-19T20:36:55Z")
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 ๐Ÿ™‚ ---
**Author:** ![bitce](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.bitrise.io/bitce/32/1639_2.png) [@bitce](https://discuss.bitrise.io/u/bitce)\ **Post date:** [July 22, 2019, 9:25am UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/8 "2019-07-22T09:25:27Z")
@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 ``` ---
**Author:** ![stefan.engel](https://avatars.discourse-cdn.com/v4/letter/s/4bbf92/32.png) [@stefan.engel](https://discuss.bitrise.io/u/stefan.engel)\ **Post date:** [July 23, 2019, 9:27am UTC](https://discuss.bitrise.io/t/cancel-running-queued-builds-if-a-pull-request-build-is-triggered/9663/9 "2019-07-23T09:27:43Z")
Yes, we just want to cancel them ๐Ÿ™‚ 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.