There's some major challenges (*) I have to address in build-flow design, so I'd prefer not to extend the DSL at this time. If you can have this packaged as a plugin that's be easier for me to ensure plugin maintenance if you can't, maybe you can use a custom build on your own ?
(*) https://issues.jenkins-ci.org/browse/JENKINS-16980 and https://issues.jenkins-ci.org/browse/JENKINS-19118 2013/8/8 James Nord (jnord) <[email protected]> > Hi Nicolas,**** > > ** ** > > Sorry for the delay but I have just been able to get around to starting > this.**** > > ** ** > > I see concurrency as an integral part of a flow manager – are you sure you > want this in a extension plugin?**** > > ** ** > > There are some advantages to it being in the main plugin**** > > **· **the state is easy to maintain – no Listeners to check for > job deletion etc.**** > > **· **Anyone wanting to do something else orchestrated across > multiple runs doesn’t have to re-invent state management**** > > **· **It is more performant as reduces the granularity of locking > required (locking Object state only occurs at the Job level not at the > Jenkins Level)**** > > ** ** > > I’ve already started on fixing the buildflow so it can run concurrently > but without some form of flow aware throttling the flows can easily > overwhelm a Jenkins instance where the trigger of a flow is happening often > (after a “source code commit build”) but the flow contains longer running > jobs (e.g. multiple levels of acceptance tests).**** > > ** ** > > e.g.**** > > ** ** > > -- begin example flow_def --**** > > build(job1)**** > > block(“longRunning1”) {**** > > // this job would take 10 minutes and give some “smoke test” coverage* > *** > > build(“bigjob”, parameter1:upstream.param.foobar”) **** > > }**** > > block(“longRunning2”) {**** > > // this job would take 30 minutes each, and has some more indepth > tests**** > > parallel {**** > > build(“biggerjob”, parameter1=upstream.param.foobar, testset= > “subset1”)**** > > build(“biggerjob”, parameter1=upstream.param.foobar, testset= > “subset2”)**** > > }**** > > }**** > > block(“longRunning3”) {**** > > // this job would take 60 minutes each, and has some very detailed in > depth tests**** > > parallel {**** > > build(“biggerjob”, parameter1=upstream.param.foobar, testset= > “subset1”)**** > > build(“biggerjob”, parameter1=upstream.param.foobar, testset= > “subset2”)**** > > }**** > > }**** > > -- end example flow_def --**** > > ** ** > > /****** > > * The block DSL ensures that only one FlowRun of a particular > BuildFlow will execute the steps contained within it concurrently.**** > > * It further will only allow the most recent FlowRun to proceed if > multiple FlowRun are waiting on the same block.**** > > */**** > > ** ** > > /James**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *nicolas de loof > *Sent:* 28 June 2013 22:43 > > *To:* [email protected] > *Subject:* Re: interogate other buildflow runs?**** > > ** ** > > I would prefer this to be part of some extension plugin. Extension point > exist so you can introduce some new SDL functions**** > > ** ** > > 2013/6/28 James Nord (jnord) <[email protected]>**** > > If I managed to get the buildflow plugin to build and pass unit tests > (master is broken on my windows box), and got my IDE to understand the > groovy stuff, and added this support is this something that you would > accept as a patch, or would you prefer that it would live in a separate > plugin as an extension?**** > > **** > > /James**** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *nicolas de loof > *Sent:* 28 June 2013 17:55 > *To:* [email protected] > *Subject:* Re: interogate other buildflow runs?**** > > **** > > this isn't possible, this require state management between flows execution > that build-flow plugin don't offer**** > > **** > > 2013/6/28 James Nord (jnord) <[email protected]>**** > > Hi all,**** > > **** > > I would like to have a buildflow job “flowjob” that kicks of job1, job2 & > job3 sequentially.**** > > **** > > The trigger for the flowjob is a successful build of “upstream”.**** > > **** > > I want to be able to run flowjob for every upstream trigger (so far so > simple)**** > > **** > > But I only want the flowjob to run as far as any other flowjob has > currently got to.**** > > e.g.**** > > if flowjob#1 is currently running job2**** > > then flowjob#1 should run job1 but not job2 or job3.**** > > **** > > to make this more interesting in the future I want to replace job2 with a > parallel invocation of job2 with multiple different parameters, and job3 > may just be another job2 but with different parameters…**** > > **** > > Is this possible? Can I get access to the Jenkins job object for the flow > to interrogate it somehow – or do I need to write an extension that I can > call.**** > > **** > > Any hints or tips greatly appreciated.**** > > **** > > Regards,**** > > **** > > /James**** > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > **** > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > ** ** > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > > **** > > -- > 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]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
