Wait for previous plan to finish building before starting the next one

Question

I have set up a Plan in Bamboo (running on Ubuntu 12.04) with 3 Stages. I'm just using the default Agent.

Builds are manually triggered via a POST request to the REST API. I want builds to be able to be queued so I've set number of concurrent builds to a high value (which seemed to be the only way to achieve this), but I also want one build to finish before the next one begins.

At the moment this is what's happening if I send 3 build requests in quick succession:

* Build #1 Stage 1
* Build #2 Stage 1
* Build #3 Stage 1

* Build #1 Stage 2
* Build #2 Stage 2
* Build #3 Stage 2

* Build #1 Stage 3
* Build #2 Stage 3
* Build #3 Stage 3

This is what I would like to happen:

* Build #1 Stage 1
* Build #1 Stage 2
* Build #1 Stage 3

* Build #2 Stage 1
* Build #2 Stage 2
* Build #2 Stage 3

* Build #3 Stage 1
* Build #3 Stage 2
* Build #3 Stage 3

Anyone know how to achieve this? Stage 2 takes about half an hour and Stage 3 sends an email, so if 20 build requests are submitted then we have to wait around 10 hours for all of the Stage 2s to complete before the emails are finally sent all at once, rather than receiving one email every half hour or so.

Nico_Jahn · Answer

Yeah, you get mostly unuseful ideas instead of answers to your question :-/

אופיר שמש · Answer

I have the same problem like John, someone know how to solve it ?

unknown · Answer

I am facing the same issue, Had to go through the same approach (Calling bamboo via its rest API). If I change the number of concurrent builds (Miscellaneous > Override default number of concurrent builds), my rest API call returns the following:

400

Build requested but not started, you have reached the maximum number of concurrent builds allowed 1. Does anyone know a way to prevent it from happening? I would like to have the same solution as John Delaney described. I know that I could have one stage only and one job and many tasks, but I'd at least like to know if there's a flag or something else easier to be implemented to avoid refactoring. Cheers,