Sorry for the confusion @bootstraponline - but we migrated this feature request during the first ones exactly to have it a bit higher than other feature requests 
We’ll soon migrate all UserVoice feature requests here (and close UserVoice completely), hopefully today, so this one will be among the top ones
Migration from UserVoice - From Jeff Remer on March 04, 2016
I’d like to see a feature that helps take advantage of the concurrency/containers by automatically aborting builds on pull requests if that pull request is updated with new or amended commits.
We’ll often submit pull requests for code reviews among the team, then either amend and force push addressed feedback or tack on commits (to squash later) - however doing this leads to lots of “stale” builds.
For example, say I have a pull request out, that kicks off a build, then I add a commit (or amend and force push) - I’d like a new build to start based off the latest commit and I’d like to have BitRise automatically abort the build based off the prior commit (within the pull request).
Basically we’d like to make the most of our concurrency/containers…we don’t care about builds based on intermediate commits or pushes to branches that aren’t
master(or some release branches) or the latest result of a pull request.
Aborting them by hand is a bit…tedious.
Sometimes i merge multiple PR’s into my build branch, instead of triggering a bitrise build for each, i would rather have a delay so that i can merge all items and then build one single app.
Thanks for the feature request @areed - moved it here as this feature request seems to cover what you described and has more votes!
Whenever someone makes a change in a PR a new build is triggered, so at the end we have several builds queued. I’ld like to free up as much instances possible so that other projects can build without being blocked.
Any update on this one?
Definitely on our roadmap, but can’t commit to a release date yet.
Should be also good to have feature to abort all builds related to pull request, if the pull request is closed (and not merged).
Can’t believe this feature request has been around since January and still not actioned.
We’re strong considering leaving Bitrise for Travis because of this very feature.
Please provide an ETA for this feature to make it to production.
I think bitrise is aware that build deduplication is the top voted feature by far. They have a small team and are doing their best to add new functionality.
Hopefully, they can provide clarification on where this fits in the roadmap.
Hi @bsarrazin,
Thank you for your feedback!
This feature is definitely planned, but unfortunately we still can’t commit to a fixed date yet.
For this feature to work and properly fit into the current Bitrise platform, we are developing our API and a couple of other product enhancements to set a solid base for other similar features.
As @bootstraponline said, we are a small team as of yet, but we’re committed to release this feature later this year.
Great news, Rolling Builds is now available in production!! 
Related blog post:
Note: for now it will only abort builds which did not start yet, will not abort already running builds.
Happy Building! 
That’s a major limitation and not how this feature works on other services. Are there plans to abort running builds?
Good news indeed! We will try it right away but we would also like to abort running builds.
We review all PRs and most of the times you need to change something. Also, most of the times those changes are small and you just want to push those and the previous build is already obsolete, we manually go there and we cancel these builds most of the times. Of course this is really annoying and auto cancelling those running builds would be really really… really nice 
Awesome thanks!
One thing though:
Could you clarify the 2 options available? I am not sure to understand if when both are disabled nothing would happen and the scenario in which it would useful:
Cheers!
In this case it is the same as not turning on rolling builds altogether. The feature’s development is still in progress, the UI is likely to go through changes later on, for example more toggles will be available.
OK thanks, I think I understand now 
Would love to add our voice too. It would be great to have option to kill all builds prior (running or queued)…at least on chosen app or for selected branches (other than master like you said Viktor).
Our purpose is continuously building develop branch - so would always desire killing prior running build and starting again. It’s iOS so having queued builds doesn’t help w/ delivery to TestFlight…and build #s etc.
Thanks though for providing the current step…it is already v. useful!
Thanks for the feedback @julesburt, definitely makes sense!
Actually, can you please create a separate #feature-request? So that we can track this separately and notify everyone who’s interested about it about the progress / when it’s finally available.
This topic was automatically closed after 22 days. New replies are no longer allowed.