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 votes
Accepted answer

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
Community showcase
Published 12 hours ago in Statuspage

194 years of downtime: looking back on incident data from 2018

Statuspage customers logged more than 194 years of collective incidents in 2018. That’s a whopping 87% increase from the  104 years logged in 2017 , and we aren’t even through December yet....

26 views 0 4
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