What about Exclusion plugin: https://wiki.jenkins-ci.org/display/JENKINS/Exclusion-Plugin
On Feb 10, 10:25 am, Dirk Kuypers <kuypers.d...@googlemail.com> wrote: > 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
