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

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.

2 answers

0 votes

Hi John,

I am wondering if setting up plan build dependencies could help you. Can you please give it a try?

I hope this helps!

Kind regards,
Felipe Kraemer
Atlassian Support

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:

<status><status-code>400</status-code><message>Build requested but not started, you have reached the maximum number of concurrent builds allowed 1.</message></status>


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,

Suggest an answer

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

Jira Ops Early Access Program Update #2: Let’s talk severity levels

Welcome to your weekly Jira Ops Early access program update, where we’re sharing news and updates on Jira Ops' progress as we work toward our 1.0 release. If you ever want to drop us feedback or idea...

33 views 0 0
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