Ok. That looks exactly what I want, looking at [1] So if I've correlated correctly, a
stage 'blah', concurrency: 1 Should give me what I want, from the documentation: A concurrency of one is useful to let you lock a singleton resource, such > as deployment to a single target server. Only one build will deploy at a > given time: the newest which passed all previous stages. Which is great, if a little unexpected. What if I wanted every build to go through a stage, just one at a time? I.E: The described concurrency:1 behaviour is great - in effect don't waste time deploying already-obsolete versions into production. What about concurrency: 1 where it's just because (say) a testing stage needs access to a resource (server|license|etc) and it's a 'one at a time' - but we want *every* build to run through that stage? A finite concurrency ≥1 can also be used to prevent slow build stages such > as integration tests from overloading the system. Every SCM push can still > trigger a separate build of a quicker earlier stage as compilation and unit > tests. This is confusing - it feels like 'concurrency' mixes up two concepts - how many times a stage can run in parallel and termination of jobs at a stage barrier based on a decision (is there a newer build waiting at this stage) ?? [1] https://www.cloudbees.com/sites/default/files/juc_sfo_oct_14-_workflow.pdf On Tue, Oct 13, 2015 at 7:09 AM, Stephen Connolly < [email protected]> wrote: > That sounds like you need the "James Nord operator" > > Workflow can do that, because the specific use case was requested by the > person it was named after > > > On Monday 12 October 2015, Nigel Magnay <[email protected]> wrote: > >> I'm migrating a lot of fairly hairy infrastructure around to use >> jerkins-workflow. >> >> At the moment, we have a number of projects that use triggering: - >> >> proj-build >> proj-ITU >> proj-robot-tests >> >> What I want to migrate is - proj-build builds every commit. proj-ITU is >> very expensive, so it gets triggered on successful proj-build builds; but - >> it only builds against *master*, so multiple triggerings will just queue >> it to build once. >> >> I'm not sure the best way to model that in workflow (or even if that's >> the best option). >> >> Something like a stage that says >> >> 1) "if there is an 'ITU' stage currently building, wait until it finishes. >> 2) If there is another build, where the build number is later than us, >> and that build started the ITU stage (or is, like us, waiting to enter that >> stage) then exit. (I.E: no point in running integration tests against a >> version that's now stale). >> >> Is that something do-able in workflow? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/CAPYP83RtRLXwCSV8ZqbpoA_cBg4OSzV-G30s9RhMgYqaoP_Y5Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-users/CAPYP83RtRLXwCSV8ZqbpoA_cBg4OSzV-G30s9RhMgYqaoP_Y5Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Sent from my phone > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMz7vmh0D8Mbdz3Cb22zrLeRUx3vBSDLkPBjr8Nrt%2BQxOw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMz7vmh0D8Mbdz3Cb22zrLeRUx3vBSDLkPBjr8Nrt%2BQxOw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPYP83RA2ZT6m5GJPRRqfiNAjOOuBQGPOj2J8SCjX-uHiKKN_Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
