Workflow question - children jobs as steps?

[Andrew Bayer]

Hey! I'm working on migrating an existing build setup with a number of individual "component" builds that both can run individually and run as part of a "full" build. I'm using the parameterized trigger plugin for all this - the component builds behave slightly differently depending on whether they're called from the full build or are running on their own (due to code changes in that individual component, etc). 

Is there a way to get this same sort of behavior in workflow land? i.e., have 1..n "jobs" (well, equivalent to jobs) that can be called individually, polling SCM etc, or be called by a parent "job" that runs the whole set of children? Or does this make more sense as 1..n actual workflow jobs, with a separate job that calls the others via parameterized trigger anyway?

A. 

[James Nord]

I'm working on migrating an existing build setup with a number of individual "component" builds that both can run individually and run as part of a "full" build

Urgh non-linear history :-( 

if you separate out the logic of the individual job into a re-usable flow script that can take your parameter then your full job is not triggering the individual jobs but is one big large flow.

And if you want to build the individual "component" you have a workflow just for that.

Is there a way to get this same sort of behavior in workflow land?

workflow jobs can be parameterized and you can trigger them with parameters.  The parameters will show up as variables inside the flow script.

[Andrew Bayer]

Yeah, separate component jobs using the global library to replace the "generic" jobs we've used for building packages on all the different platforms we support, and the "full" build launching the component jobs via workflow as well seems to be the direction that's making sense for the use case. And fwiw, it's all linear history for the component jobs - just sometimes they're run directly, sometimes they're run by the full build. 

A.

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/203abdf4-dffd-4207-acaf-e2f784e028b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Magnay]

Is it possible for workflow-multibranch jobs to take parameters?

I have a similar requirement where I'd like a 'parent' workflow job to trigger some number of downstream child jobs, probably with something like (despite the warning in the snippet generator, I don't care to wait for the outcome or if it errors)

build job: 'DownstreamProject/branch', propagate: false, quietPeriod: 0, wait: false, parameters: [upstream:'${env.BUILD_NUMBER}']

Aaactually, what I'd *really* like is for a workflow build to fire an event on completion, and have arbitary downstream (multibranch) projects subscribe to those events.

Thus if my 'product, development' branch builds successfully, then my downstream 'customer config, development' projects automagically trigger a build based on these new artifacts that have become available.

I could probably lash something together in a custom plugin, but I don't know if this is catered for in an easy way?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAPbPdOaTvsSU5NrSSZD1eTpwnGy1e%2BDi6TVODSW_grUX0ELQtg%40mail.gmail.com.