Prevent Concurrent Builds of a Branch


I have two different product branches (master & integration) that, as part of their deploy step, perform a deployment to Amazon ElasticBeanstalk. But the deployment fails when another deployment is in-progress.

I’d like the ability to prevent multiple concurrent builds of the same branch, in the same project. The builds would sit “queued” until the running build on that branch completes. I could do this already by having my deploy commands detect if a deploy is already in-progress, but, then I’d be using up one of my containers just to sit around and do nothing.

Circle keeps breaking my deployments because it doesn't prevent concurrent builds on a branch
Sequentially Running Workflows

I would also love to see this feature added!


I think this feature request is a great idea! While it’s not exactly what you asked for, I do recommend checking out this thread for serializing your deployments in the meantime.


+1 I would love to see this changed as it’s probably the only aspect of CircleCI I actively dislike. There’s no situations where I would want 2 builds of the same branch to deploy simultaneously. For us it’s just really ripe for race conditions.


I’ve been looking for the last 2 years for a cloud based CI server that has this functionality with one minor amendment: I need to use regex to match the branch names to not build concurrently. For example, feature/.* should only ever build one at a time but my master branch should be able to build concurrently with a feature branch build since they rely on different external resources.

I wrote up more detail about our use case on StackOverflow and it appears at the moment that Jenkins is our only option.


Thanks frank.

I’m having trouble getting this solution working though. I’m fairly certain I’ve setup all the pre-reqs, but when I try to use the scripts I see the following:

: No such file or directory ./do-exclusively echo "testing" returned exit code 127

Any ideas?

EDIT: Please ignore. I am using filthy Windows and just realized the line endings were defaulting to CRLF****



I have the exact same use case as the OP


Thanks, rdbaron! You just saved me a lot of time! :smiley:


We have added functionality to auto-cancel redundant builds. If this feature is turned on, we will automatically cancel any queued or running builds on a branch when a newer build is triggered on that same branch. To enable this feature you can navigate to “Advanced Settings” for your project and enable the “Auto-cancel builds” option.


@rishimkumar that feature doesn’t really solve my problems, much like the OP I suspect.

I don’t want to cancel newer builds, I only want to queue them.

Are you aware if this is something we can expect?


@rishimkumar I agree. We need the earlier builds to run as well (you might want to see at which point the build breaks, or ordering of deployment based off commit placement) and would only want later builds to sit as queued.


Thanks for the feedback. We’re actively working on a first-class job scheduling system where you’d have much more control over what gets executed and when.

Thank you so much for your patience.


Thanks @KunalJain, look forward to hearing about it!


Is there any news on this @KunalJain? it really seems like a fundamental option to have?

We are basically not paying for concurrency because it just doesn’t work for us as it can potentially leave us in an undetermined state.


Are there any plans to address this? Current situation can lead to serious mess. Only way to deal with this is to block all the pipelines for single app, regardless if the app can actually utilize concurrency.


We’d also very much like a feature that allowed us to have all builds of a specific branch happen in sequence. Parallelism within a build is still completely fine. We just don’t want the “deploy all files to our server” step to happen at the same time on two different builds of the same branch. They must happen in sequence.

Race conditions creep in more and more often as our team grows. Hope to see this addressed soon.



We would also really appreciate this feature, for the same reasons that are mentioned in other comments.


Agreed, we need this feature too (queue builds, don’t cancel them). They aren’t “redundant” if they are on different commits.


We could really use this feature too +1


this is still a critical missing feature - 2.0 doesnt address it in any way that I can find, it only restructure how parallelism inside a job/build/workflow are managed (and not exactly for the better, either, but that’s a different issue)

also, the auto-cancel-builds feature only works for non-default branches. your default branch will still happily concurrent builds if nodes are available.

With the exception of your default branch, ...