On 13 October 2015 at 08:40, Nigel Magnay <nigel.mag...@gmail.com> 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 > <stephen.alan.conno...@gmail.com> 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 <nigel.mag...@gmail.com> 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 jenkinsci-users+unsubscr...@googlegroups.com. >>> 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 jenkinsci-users+unsubscr...@googlegroups.com. >> 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. 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.
