[JENKINS-263] Preserve build order of downstream projects - Post-build Actions Build Other Projects order is not maintained

[timja]

Scheduling "Projects to build" in "Post build Actions" should preserve their order.

When I view "Downstream Projects" they appear in the order they were entered.
When they are eventually put on the build queue the order can be different.

Resolving this issue would allow me to first build all target containers and
subsequentially run all tests against those containers.

Affects: 1.74

---

Originally reported by tdiesler, imported from: Preserve build order of downstream projects - Post-build Actions Build Other Projects order is not maintained

• status: Reopened
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

tdiesler:

Related to this, "Projects to build" should maybe be a multiple select box,
rather than a text field.

[timja]

kohsuke:

Isn't it just a multi-level dependency? That is, you want the dependencies to be

A +> X1 ---> X2

+-> Y1 ---> Y2

+-> Z1 ---> Z2

?

Or are you saying that it's actually more like the following, where you only
want to build B after all 3 has finished?

A > X1 > B

-> Y1 -

-> Z1 -

[timja]

tdiesler:

Its more like this

containers +> C1

+-> C2

+-> C3

run-tests +> T1

+-> T2

+-> T3

To run the tests I must have build the containers, but I don't want to do it
every time as a dependency of the tests.

qa-matrix +> C1

+-> C2

+-> C3

+-> T1

+-> T2

+-> T3

For the QA matrix I want to do all, but the order of building the containers
must be preserved

[timja]

gradopado:

When your build server(s) has more than one executors preserving order wouldn't help. I think in
Hudson's current concept it is not possible to set dependencies like this without duplication. If we had
another level in the job concept where you could define a build, then you could set up jobs using those
definitions of builds. These jobs would share the same build definition but could have different
dependencies.

[timja]

tdiesler:

By the nature of my projects I only have one executor.

What is the benefit of queueing jobs differently as they are specified in "Post
build Actions|Projects to build"?

[timja]

gradopado:

> What is the benefit of queueing jobs differently as
> they are specified in "Post build Actions|Projects to build"?

Of course, if you have only one executor, I would expect to see them executed as
defined in this list. But for more than 1 executor the order is just not defined.

[timja]

kohsuke:

I think the bug report is valid because I don't see any reason why Hudson can't
preserve orders.

gradopado is right that relying on that to do a chained build is rather fragile
(for example a difference in quiet period can disturb order, so is the multiple
executors and master/slave, and in this approach you can't cancel T1 even if C1
fails), but nevertheless I don't see why we shouldn't fix this bug.

tdiesler, if you can tell me a bit more about where you see the order gets lost,
that would be really helpful. I looked at the code, and the build trigger does
trigger builds in the specified order, and the queue generally tries to maintain
its order.

[timja]

kohsuke:

We really need some input from the reporter to make progress.

[timja]

kohsuke:

No further input from the submitter. Closing for now.

[timja]

timp:

This behaviour is still exhibited in Jenkins 1.397.

I enter a comma separated list in 'Projects to build' and they are added to my one-wide work queue in alphabetic order, not order specified.

Scenario is a maven multi project, parent build not recursed.
Next some utility jars must be built. Finally the targets.
If they are built in a different order it fails.

I am aiming towards a getting the Maven release plugin to play nice.

Projects can be viewed at http://jenkins.cggh.org/

[timja]

cactus:

Confirm that for me, the order is taken from the alphabetic job name.
Any news from this bug or someone interest in solving it?

[timja]

krissap:

This bug still applies to jenkins 1.418.
A workaround I found is, instead of using "downstream projects" native feature, you can launch the execution of any jobs using a shell script with the following command:
wget ${JENKINS_URL}/job/${YOUR_JOB_NAME_HERE_1}/build?delay=0sec
wget ${JENKINS_URL}/job/${YOUR_JOB_NAME_HERE_2}/build?delay=0sec
wget ${JENKINS_URL}/job/${YOUR_JOB_NAME_HERE_3}/build?delay=0sec
...

This will launch 3 jobs in the exact order they are listed above.
OK this is not clean at all, but at least it works!

[timja]

cactus:

tanks for the patch idea, better than nothing.

[timja]

tdiesler:

Out of Date

[timja]

timp:

Err, 'Out of Date' ?
Fixed or no?

[timja]

tdiesler:

I don't think it is fixed, please reopen if it is still relevant for you.

[timja]

jeremympope:

I am experiencing this issue having upgraded from 1.509.3 to 1.509.4. The order of jobs executed does not seem to consistent from execution to execution.

[timja]

nicktulett:

I've got 20+ test jobs to run on 8 slaves. One job takes 6 hours and I'd prefer it if this ran first, then the rest in duration order.
This running in an unknown order business means this job never runs early, so the entire test suite takes nearly 12 hours, when it should be possible to squeeze it into 6.

[timja]

oleg_nenashev:

The issue is not a bug.

You can use following plugins to get the functionality:

• Build Pipeline Plugin
• MultiJob Plugin
• FlexiblePublish + Parameterized trigger

[timja]

timp:

Oleg,
As Kohsuke says above: it is.

The list of downstream jobs should be represented as a list and executed in order specified. Reordering alphabetically is a bug.

[timja]

oleg_nenashev:

@Tim
I've reopened the issue and set the proper component

[timja]

timp:

@Oleg great

[timja]

madleeen:

How is this going? Is there any way to do this - some workaround? (I mean without other plugins.)

[timja]

btb3:

madleeen I have found a workaround:

We use the PrioritySorter plugin anyway to sort our jobs, so we actually want then to be started in priority order (which you also can do dynamically with the BuildPriority parameter. This bug here prevents the starting in priority order, because jobs are run before all parallel downstream jobs are fully pushed into the queue.

What I did was to set a global Quiet Period of 5 sec in the Jenkins Options, so that each and every job (unless otherwise specified(a)) will stay in the Queue for 5 sec - this is enough time so that all parallel downstream jobs get pushed into the queue together, therefore allowing the PrioritySorter Plugin to sort them accordingly.

(a): Neat thing is the GUI buttons will add a delay=0sec, so that starting the inital job won't have any delay. If you have URL triggers, you can also spec. the delay there if the 5sec is hurting.

[timja]

[Originally duplicated by: JENKINS-2002]