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.
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.
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 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...
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!
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