Do not cancel builds on same branch if another workflow is triggered


We wanted to split up our CI into separate workflows that are run if need-be.

However because we have enabled rolling builds it will cancel the previous workflow that triggers another workflow, because only one build can run for a given PR/branch.

I think it would make sense to allow multiple different workflows for the same PR/branch. Although if there are two identical workflows being run, then it should probably cancel the old one.

Rolling builds per workflow
Rolling builds per workflow
'Bitrise Build Start' step aborts current workflow if Rolling Builds is set to cancel running builds
ENABLE ROLLING BUILDS aborts a build on a different workflow
Exempt manual & scheduled builds from rolling builds

Thank you for the feature-request @j.kaan! :rocket:
(pls don’t forget to vote as well :wink: )


I think manually created builds & scheduled builds should be exempt from build cancel logic.


I think this is a great idea @bootstraponline, I’m just worried we’ll slowly overwhelm the UI with options…


Say I have one open PR:

  • branch1 > master

that triggered a build “Check-PR” #1 which is currently running.

I think I observed that if in the meanwhile I open a second PR “branch2 > master”, the rolling build feature will abort #1 and trigger a “Check-PR” build #2. Eventhough the 2 PRs do not originate from the same branch (branch1!= branch2).

Then again, while #2 is still running if I push on branch. It triggers a third build #3 that aborts #2.

Instead, for me expected behaviour would be :

  • Opening the PR “branch2 > master” does not abord currently running builds regarding PR “branch1 > master” similarly pushing on branch2 does not abort currently running builds regarding PR “branch1 > master”
  • Pushing on branch1 while a build regarding PR “branch1 > master” is running abort that last build and starts a new build (but do not abort build regarding PR “branch2 > master”)

In short “rolling build” should abort older running builds having the exact same couple “branchToBeMerged/targetedBranch” not just having the same “targetedBranch”.

Is that clear ? Is that the same feature that is requested by @j.kaan in the current thread ?


I think it should be how the feature works, not an option.


Are you sure about this? If you’d see this happen please open a #issues:website-issues issue report as that’s a bug which should not happen - two separate branch’s builds should not abort each other.

Correct, that’s how rolling build is expected to work even today. This feature request is not about that, it’s about NOT aborting builds on the same branch if those builds are running with different workflows (e.g. both builds running on master branch but one is running with WF1 the other with WF2 those should not abort each other even though both are running for master branch).


Can you create a separate #feature-request for that @bootstraponline? That use case might be higher priority than the workflow based one.


Sure, here’s the new feature request:


I agree! Having Rolling Builds turned on breaks this feature

If I spawn multiple builds (different workflows) with the same branch and have Rolling Builds enabled, then a only the last build will be running.

EDIT: Guess there is an issue reported for what I just described too.


We’ve just rolled out this feature, from now on only builds triggered on the same workflow gets aborted when a new build is started. Thanks for the feature request and let me know if you have any questions!