Hi Didier, are you sure? I am using it already for some jobs which I do not want to run concurrently. But how could I achieve that my compile job waits in the queue until the last downstream job entered the state running? If all downstream jobs are running it is save to start the next upstream compile job. But maybe I overlook something. And: it is a proposed deprecation:
https://wiki.jenkins-ci.org/display/JENKINS/Proposed+Plugin+Deprecation The "Throttle Concurrent Builds Plugin" also only allows to control the executor nodes. I would need to have control about the waiting queue... I have played with priority sorter plugin but it did not work reliably for me. Any other idea? Dirk 2012/2/10 Didier Durand <durand.did...@gmail.com>: > Hi, > > Lock & Latch plugin should help you achieve what you need: > https://wiki.jenkins-ci.org/display/JENKINS/Locks+and+Latches+plugin > > regards > > didier > > On Feb 9, 3:42 pm, Dirk Kuypers <kuypers.d...@googlemail.com> wrote: >> Hi, >> >> is it possible to block a build as long as downstream projects are >> queued, but not running? >> >> Background: We have a continuous compile job triggered by SCM changes >> which starts about 30 unit test jobs after successfull compile. Most >> test jobs copy their workspace via copy-workspace-scm plugin from this >> compile job. Compile takes about 5 minutes, some test projects 10 >> minutes and longer. The round-trip build cycle is around 18 minutes at >> the moment. When I disable "Block build when downstream jobs are >> running" at the compile job it will happen, that there are some tests >> queued from the previous build which will get started after the second >> compile is successfull. So those tests get their workspace from the >> second compile and not from the first one. If the second compile job >> had to wait untill all remaining tests left the queue and entered the >> state running I think it would be save to start the next compile (and >> could save us about 5 minutes in our build cycle). >> >> Another possibility would be to tie the unit-test job to its starting >> compile job with the workspace attached and not to "Most recent >> completed build". >> >> Any thoughts on this? Any other way to achieve my goal? >> >> Dirk >> >> -- >> Never trust a short-haired guru -- Never trust a short-haired guru -- Never trust a short-haired guru
