On 13 October 2015 at 08:40, Nigel Magnay <[email protected]> wrote: > 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?
Welcome to the fun that is the "James Nord operator" I suggest you have a chat with James, it was his use case after all ;-) > >> 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. >>> 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. >> >> 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. -- 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%2BnPnMyD_Svvrk60DwrwRvhF6C-aFamn%2Bo07kZC31F-Tzi6R1g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
