It is but it depends on what the use case really is. By declaring build parameters on the jobs you can fire any job at any time with any value, those values can be fed by a property file if triggered by an upstream job. There are pros and cons to both approaches and the ideal solution would be to feed the build parameters with the default values of a property file.
Anyway if there is a lot of parameters to feed this may be an indication that the pipeline is too abstract and generating specific jobs preconfigured with some of the parameters could be a better solution (especially to prevent spaghetti build history of jobs). Cheers, syl20bnr Le mercredi 10 juillet 2013 15:41:20 UTC-4, Daniel Beck a écrit : > > How would this solve the complexity problem of manually triggering > downstream jobs? Quoting Maureen: > > > In my case the processes are fired off at different times. The same > parameters have to be set on each top job which seems like too many moving > parts to me. > > > --- > > Adding an Env-Inject build step (or build wrapper) also adds a page called > 'Environment Variables' to each build listing all defined environment > variables for that build. It includes the ones loaded from the properties > file. Of course, they're among 50 or so others, but it's not like that > information is just gone. > > The one advantage of actual build parameters is that they're set before > SCM, so you can add some variables there. OTOH my approach allows triggers > e.g. based on SCM changes without maintaining default job arguments for > several different jobs. > > --- > > Another option would be to register with Cloudbees (it's free) and get the > Folders Plugin. It allows defining environment variables that are made > available for place holders in the configuration of child jobs. > > Example 1: In the folder, define 'RELEASE_NAME=foo'. In the job within the > folder, specify the SCM URL ' > https://server/svn/branches/$RELEASE_NAME/subproject' > Example 2: In the folder, define 'RELEASE_NAME=foo'. In the job within the > folder, specify the Env-Inject 'Inject environment variables to the build > process' as 'RELEASE_NAME=$RELEASE_NAME' (yes, really). Then you can access > the environment variable RELEASE_NAME from build steps. > > This works best for static configuration though, like folders specific to > branches defining the branch name to be inserted in SCM configuration. Just > wanted to mention that option, even though the copyartifact/env-inject > combination actually seems more appropriate. > > On 10.07.2013, at 20:08, syl20bnr <sylvain...@gmail.com <javascript:>> > wrote: > > > You can also use the build parameterized trigger plugin you already use > to read from the property file using "Parameters from properties file". The > plus sides are that build parameters are recorded in build histories and > the values will be set before that the SCM step occurs. > > > > Cheers, > > syl20bnr > > > > Le mercredi 10 juillet 2013 06:16:19 UTC-4, MoBarger a écrit : > > I like it! I was thinking about a properties file but never thought of > > creating it as an artifact! Thanks for the idea! > > > > On Wed, Jul 10, 2013 at 6:09 AM, Daniel Beck <m...@beckweb.net> wrote: > > > In a similar situation I defined one job ("Configuration") that > created a .properties file with the relevant options based on job > paraemters and archived it as artifact. > > > > > > The other jobs then used the Copy Artifact plugin to get the file > ("Copy from last successful build" uses the current option set), and a > build step defined in Env-Inject to inject those options into the > environment for subsequent build steps. For more flexibility, use a build > selector parameter, or specify a build number as string parameter and copy > artifacts from a 'specific build'. > > > > > > On 10.07.2013, at 11:13, Maureen Barger <moba...@gmail.com> wrote: > > > > > >> Right, thanks, we do use that and it works well. But this works best > > >> when one job triggers another. > > >> In my case the processes are fired off at different times. The same > > >> parameters have to be set on each top job which seems like too many > > >> moving parts to me. > > >> Ideally I could set up a job which only defines the release number > and > > >> a couple other parameters that would be referenced by each kickoff of > > >> the process (ie build, deploy, test, package). > > >> > > >> On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr <sylvain...@gmail.com> > wrote: > > >>> You should be able to do this with the Parameterized Build plugin ( > https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work > we use Perforce and we use this plugin to pass the variable P4_CHANGELIST > to downstream job (with the perforce plugin configured with P4_CHANGELIST > as a label). It works fine. > > >>> > > >>> Now you write that you have several build parameters. Depending on > how you use them it may lead to mess your build history with the same job > called with different parameters. > > >>> You may want to look at Job Generation plugins like JobCopy Builder, > Job DSL and Job Generator. I'm the author of the last one. :-) > > >>> > > >>> Cheers, > > >>> syl20bnr > > >>> > > >>> -- > > >>> 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. > > >>> 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 jenkinsci-use...@googlegroups.com. > > >> 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 jenkinsci-use...@googlegroups.com. > > > 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 jenkinsci-use...@googlegroups.com <javascript:>. > > 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 jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
