Priority builds


We have some builds that only build + test whereas other builds have deployments attached. We’ve encountered problems where theres ‘build+test’ builds will hold up a deployment. I’d like to have a way prioritize deployment builds over other builds that dont deploy.

Is a Priority Builds feature planned?

Likewise, we’ve been running into this and hope for a similar solution:

Our team has been getting hung up a lot lately when we have a single build that one person is waiting on more urgently than the other builds in front of them in the queue. Right now the only option is to cancel those builds, then re-build them.

It would be so much simpler and easier if we could just promote a single important build to the front of the queue, and not fill our logs with all the cancelled messages or have to coordinate among each other about cancelling and rebuilding.


Thanks @sthomp and @dsernst for the feedback :slight_smile: This is a popular issue, we hope to see if available soon.


Couldn’t agree more. We have around 20 developers checking in multiple times a day into their feature branches. Each triggers a build on Circle CI. However there are some branches/builds that have to go immediately (like an urgent bug fix). They end up waiting in the queue. It is extremely frustrating to cancel other builds (and enqueue them again for later). Some way of prioritizing will definitely help.


Do you know when this is going to be online? :smiley:
Would be awesome this feature. Like the others we struggle a lot with this.


+1 We also have need for this kind of feature. Basically the ability to change the scheduling of builds, limit max concurrency consumed by a given repo and a button to “bump” the build to the back of the queue or “promote” it to the front.

some sample usecases:

  1. I want branch = master builds to go before all others. Why? Because these represent deploys of new code and other devs can wait.

  2. I want to limit the concurrency of a given repo. Why? Because I have builds that take 20 minutes and if I get enough commits in a short time, all my other builds are behind the 20 minute repo. Thus i need a way to ensure that other repos can build even if I have lots of long builds in queue. example setup could be w/ 5x parallelism I set the long repo to only be allowed to have 3 concurrent builds. Thus 2 will remain for other repos. Basically using pigeon hole principle to ensure sufficient concurrency remains for other builds.

  3. I want to be able to promote a build to the front of the queue. Why? because sometimes an important build is stuck behind long/unimportant builds and I need to get a bug fix out

  4. I want to be able to demote a build to the back of the queue? Why? because sometimes I dont care when a given build will complete, just that I can see its log of completion later.


Hi @levlaz , can you give us updates on this issue? Thanks much!


Your best bet for now is to cancel builds and re-build as necessary. However I can imagine a scenario where builds that trigger a deploy being able to have a higher priority.


I went hunting for this feature and was sad to find multiple forum threads discussing it, but no implementation.

My use case is that I want to push a build product from CircleCI and use it later during deploys to our live environments, but don’t want to incur the latency between code push to code live due to the unpredictability of queueing.

Any sort of prioritization would help us.

  • prioritize a given job including killing and requeuing jobs that are running
  • pay a little extra for “burst containers” when certain criteria are met from time to time.
  • push to top of queue (partial fix since still a notable delay is possible if long running builds are using all containers)

Our solution has been to handle this process separately out of CircleCI, which is obviously not ideal.


Caveat - I do not think this solves everyone’s issues here but I’d like to point toward this somewhat recently launched feature:

Option to auto-cancel redundant builds
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.


We keep on having to increase our containers in order to be able to tolerate the wait time. Looks like this has been a popular request for some time, any chance it is being worked on?

I was told I could setup a separate account to do this, but I don’t see how that is supported either.


Yes! This is actively being worked on as part of a bigger project to give more pipeline flexibility to customers. I don’t have an ETA but we’re spending a good bit of our resources on this so I’d expect us to try and market it as best we can once we’re done :slight_smile:


Any updates? After S3-geddon, we have dozens of builds running before master


Any updates on allowing to prioritise deployment builds ? Whats the ETA - I think this thread is open since 2015 now. ?

This missing feature makes it impossible for us to use CircleCI for auto deployment purpose. CircleCI is then just a tool for running our specs / unit test builds and not a fully functional CI.

Meantime, I think we are left with no other option but to evaluate other tools / apps that gives us these fully functional suite of tools for CI.


Really, CircleCI, could you please implement that? I just joined a project that uses this today, and I am being severely impacted to release quick fixes for the client because I’m waiting for almost 20 min for a machine that’s running unimportant jobs from other projects in my company. This feature would be really nice!


Yeah, +1 to this. Our important builds are often significantly delayed due to less-important branch deploys being prioritized.


I was just about to create this feature request. Very much needed.

We’re also power users of CircleCI and the scenario for us is also to prioritise deployment builds over feature branches that are not being deployed.

Could be achieved with priority: <integer> type of setting on a job that is part of the deployment workflow. You’d then have to cascade down the chain to identify if there are priority jobs, in order to reserve parallelism to the workflow that includes a priority job.


Hello! Users have been asking for some kind of build prioritization for >2 years.

Can you provide any insight into if/when you’ll build such a feature, or if we should continue to implement workarounds for it?

Example use cases for us:

  • master builds >> non-master builds => would love a way if we could reason about priority by branch
  • ~“update all our Golang repos from Go 1.8 to Go 1.9”. Say we want to push commits to 100+ repos for this change during the workday… If so, we are blocking developers from making other changes while this bulk change is running builds for everything. Even if we wait until the night to run it, it’s still blocking the build queue if there were any emergency. => would love a way if we could reason about priority per commit

closed #19