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.ben...@gmail.com> 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-users+unsubscr...@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-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
