Change Log

V1.1 @ 07/20/2012

V1.0 @ 05/18/2012

Author

6 Comments

This plugin is great! It helped reduce the number of irrelevant builds in my environment by about a factor 5 at least and did not require any configuration at all.

I do, however, have a suggestion for a feature.

Consider the following scenario:

You have two regular jobs, A and B.

In addition you have a parameterized job C (e.g. a batch job that signs artefacts).

A and B invoke C as the last build step and wait for C to finish before determining Success or Failure.

What can happen is that A finishes up to the point where it invokes C. However, if the build queue already contains job B, it seems that dependency-queue-plugin detects the dependency of B on C and does not permit C to run before B has run. B however may not be able to run as long as no processor for B is available. This causes A to lock up because C does not return. Of course I could remove the flag on A and B that causes them to wait until C finished - but then I effectively loose the error reporting on A and B if code signing failed.

It would be great to have a means of telling dependency-queue-plugin to ignore certain dependencies (e.g. a flag on job C that causes dependencies on C to not be considered when figuring out the build order).

No, I did not find a solution - in the end I just increased the number of build nodes until the likelihood of this problem was reduced so much that it was negligible.

However, since updating to Jenkins 2.x for the sake of having pipeline-as-code support the Dependency Queue Plugin seems to have stopped working entirely. Maybe a side effect of the new project types introduced recently? A shame really. Dependency Queue Plugin in my opinion was probably the best, at the least a massively underrated approach to bringing a suitable order to your build queue using just the configuration you have to provide anyway rather than requiring you to form project or priority groups. It's mind boggling that its functionality is not built into Jenkins natively. Without taking the up- and downstream dependencies into account while processing the build queue, the majority of the time spent by the build nodes has been for naught (unless you have no more than two or three layers in your dependency graph...).

You're right, the author was very brief in the description. Technically speaking, however, the short sentence says it all: The plugin makes sure that the build pipeline is processed in an order that takes into account the project's dependencies. Consider a case where you have two shared libraries (project A and project B) as well as an executable that uses both shared libraries (project C). Now, if you build all three projects, then there are only two sequences that actually make sense: ABC or BAC - any other sequence will lead to unnecessary overhead because C gets built more than once (e.g. ACBC or BCAC or CABC or CBAC or ...)

This may not sound like a lot. But if instead of just three inter-dependent projects you are dealing with a few dozen, each with a build time of roundabout 1 hour then the unnecessary overhead caused by Jenkins being completely oblivious to the dependencies while populating the built queue is getting infuriatingly significant. Dependency Queue is not the only but the most elegant solution to the problem because unlike other plugins that try to do a similar thing, Dependency Queue does not require any additional configuration to do its job - it simply evaluates the information that is already there anyway...

To all those who updated to Jenkins 2.x and stumbled across the issue that the Dependency Queue Plugin is not working any more with the newer builds of Jenkins: The last GitHub commit (23.12.2015) gets it up and running again.