Scrap my last comment, this doesn't appear to work. Maybe if you had the same
number of Build Executors as you had projects, and you used this mentality, it
might work. But after running a test, even if one of the projects takes too long
to pull from SCM, it throws the whole thing off and everything build breaks
again in a big steaming pile
.
I can second the need to have build priority! The build priority should take
over from the Quiet Period, i.e. if Project B (that depends upon Project A) is
in the Quiet Period for 1 minute, and Project A is in the quiet period for 10
minutes, Project B should be queued until after Project A has completed (i.e. at
least 10 minutes away).
In my case we have 7 projects (named A-G for simplicity).
Project A is a root library
Project B depends upon A
Project C depends upon A and B (and is an end application)
Project D depends upon A and B (library)
Project E depends upon A and B (library)
Project F depends upon A and B (library)
Project G depends upon A, B, D, E and F.
Thus if I make changes to say Projects B, C and G, I would expect the build to
actually build B, then C, then D (it depends upon B), then E (it depends upon
B), then F (it depends upon B), then G.
Many thanks,
David (a different David to the original)
Unfortunately things like queue cannot be really extended by plugins — I can't
think of any good way to let plugins do this without interfering with each other.
However, there have been some discussion about allowing one plugin to subclass
Queue, so maybe that would let you do something like that.