Concurrent Builds and Queue builds

[Simon Harrison]

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

[Simon Harrison]

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.

[Gary Donovan]

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

[Gary Donovan]

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

[Marcin Gardias]

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.

[Simon Harrison]

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

[Patrick Simon]

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