How can I have a particular job in a stage run sooner that other jobs in the same stage?

I have four jobs in the same plan in the same stage that represent four different build configurations of one of our products: Win32/Debug, Win32/Release, x64/Debug, and x64/Release. I would like to keep these jobs in the same plan so that all configurations share the same build number.

Because of resource constraints, the Win32 and x64 jobs go to two remote agents (rather than four). I would like the Win32/Release job to be run ahead of the Win32/Debug job, and the x64/Release build run before the x64/Debug build, but I don't want to put the Debug jobs in a separate stage because that would mean that the x64/Debug build to wait for the Win32/Release build to complete.

Is there any way to order jobs within a stage?

4 answers

1 accepted

0 vote

You cannot achieve this, sorry. You have to assume random/not guaranteed order for Jobs in a single stage and every stage has to be completed before another one runs.

Since Jobs within a Stage execute in parallel I would say that if Win32/Release and Win32/Debug Jobs are tied to the same agent using Capabilities then you can achieve what you want. If they are tied to a specific agent, then they cannot run in parallel. However if that isn't realistic and you have multiple agents they must be able to run on I'm not sure how it can be done unless you split the Debug Jobs out into separate stages.

I relented to partition the debug jobs into a subsequent stage. One negative side effect is that the debug stage is only executed if both release jobs in the release stage pass.

I guess I'll just have to work toward getting more remote agents. :-)

You can just put in a "lag" task of your job that does nothing but sleep for a given amount of time...

Just make a script task at the top of the jobs you want to slow down for a certain amount of time and type in:

"ping -n 30 127.0.0.1 > NUL 2>&1"

Where the "30" is the time in seconds you wish to lag. I know the command looks wierd, but windows doesn't really have a "sleep" option to wait for a task to be complete. Basically what this command does is ping the machine 1 time per second 30 times... hence the 30 seconds...

But Adam and Przemek are correct that you can't guarantee that both of these jobs start at the same time because of agent availability. You could have the "lagged" job start and the task you didn't want to lag waiting for an agent to be available for 30 seconds... therefor this wouldn't be a good solution...

Another unfortunate consequence to having to relegate the debug build jobs to their own stage is that they don't run when either of the release build jobs fail. :-(

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Renan Battaglin
Published May 18, 2017 in Bamboo

FAQ: How to Upgrade Bamboo Server

Bamboo 5.9 will no longer be supported after June 12, 2017. What does this mean? As part of our End of Life policy, Atlassian supports major versions for two years after the first major iteratio...

1,493 views 0 5
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