Concurrent Builds and Queue builds

I am wanting to queue builds of a plan with differing parameters passed in, But I can only queue up to the concurrency limit.

I don't need the builds to run concurrently, but i do want to queue the builds:

Using the REST API queue would indicate that this is possible, ".. this method adds build to the build queue, so is not guarantied that build would be executed immediately.."
however when the concurrent build limit is reached you receive the message "Build requested but not started, you have reached the maximum number of concurrent builds allowed."

It seems to me that build concurrency concept is confused with or merged with a queue limit?

Why do I want to limit the queue?

I understand limiting concurrency of a build but this should apply to agents, not to the queue.

Thanks,

Simon

4 answers

0 votes

Hi Simon,

This is intended behaviour. 'number of concurrent builds' controls how many builds of the same plan can be queued or built at the same time. The reason is that if for example a lot of people commits their code in a short time, queue would become big. If there are not enough agents to consume the builds and/or builds take long time to complete, developers wouldn't get their results in reasonable time.

If the queue is limited, commits are grouped together and built in bigger chunks. So it's really about the tradeoff between having fine grained built results and getting the results fast. You can't always have both ;-)

If you don't mind your builds staying in queue simply raise the limit. You can do it either globally (Administration -> Concurrent Builds) or on per-Plan basis (Plan Configration -> Misc. tab)

Number of builds actually running is controlled by number of agent capable of running the build.

Thanks Marcin,

I would suggest that commit grouping would be better handled by the tiggering functionality of the plan, this is where the repo polling frequency currently balances the grouping of commits, if you are using the 'repo triggering' the incoming trigger events could be 'batched up' to achive this outcome.

Limiting the queue just drops the last trigger. If the queue is full, then the last trigger is denied, if all build jobs have started, changes in that last commit will only get built upon the 'next' commit and only if the build queue has space.

Thanks,

Simon

What Simon said. The current doco for this at https://docs.atlassian.com/bamboo/REST/5.5.0/#d2e820 is misleading 

Simon,

I agree that it is unhelpful to combine the build concurrency with the build queue length. This seems to be part of a larger problem where is it quite difficult to manage the build queue in a satisfactory way

Let me know if you find any good solutions.

gary

Simon,

I agree that it is unhelpful to combine the build concurrency with the build queue length. This seems to be part of a larger problem where is it quite difficult to manage the build queue in a satisfactory way

Let me know if you find any good solutions.

gary

The only workaround I found is to set the max concurrent build on the plan to a high number 150, to ensure that each triggered build gets built.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Monday in Jira Ops

Jira Ops Early Access Program Update #1: Announcing our next feature and a new integration

Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...

529 views 0 9
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you