Auto-cancel redundant builds for specific branches
D
David Provencher
We basically sometime have a few branch that are long feature branch that are associated with an ephemeral environment. It follow the same worfklow as the main branch, where dev fork-off a private feature branch and then merge back into those long live branch.
Similarly to Sam Kemp, those build take 20+ minute to complete and any dev merging his change to that branch cause a cancelation of the previous one.
We basically like to have a full test run done on these branch everytime a pr is merged, since a pr represent a atomic unit of deployable code change in our workflow. That unit upon completing the CI part then proceed to be deployed.
Cancelling the test when a new pr is merged, mean that we skip testing that unit independance.
As part of the test, we capture screenshot and document the UI change. These are also not completed and when a screen change it is not obvious which pr caused the UI change since it encompass 2 or more pr merge.
M
Manuel Baesler
Same reason as Sam. We want to have all builds on the main branch as well as release branches, but on private branches we only care about the latest commit. Our solution was to disable auto-cancel globally and implement the cancel logic directly in the pipeline using the CircleCI API: https://github.com/arangodb/arangodb/blob/6b8774968fc59ce9d704f5c19c8a53e306022161/.circleci/config.yml#L99-L135
Minjun Seong
Hi folks, I'm a product manager at CircleCI. Would really appreciate if you can elaborate on why you wanted to disable auto-cancel redundant builds for specific branches? Was it for the same reason as mentioned by Sam or something else?
Sam Kemp
This is desperately needed. For private feature branches it absolutely makes sense to cancel redundant builds but if there's a public branch such as a trunk where multiple devs push to it then cancelling the build leads to massive frustration. We have a workflow that takes 20 minutes to complete but if any dev pushes to the branch during that 20 minutes then the first dev has to wait another 20 minutes before their change is deployed. Turning it off though would result in so many redundant pipelines running in private branches.