nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Sean Dockery

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?

Accepted answers

Przemek Bruski

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.

All comments

Adam Myatt2

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.

Przemek Bruski

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.

Sean Dockery

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. :-)

Cameron Ferguso

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

Sean Dockery

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. :-(