Correct me if I'm wrong, but won't the ENVInject plugin accept token macros? That would let you just drop the build parameters right in there. Seems like an ideal solution, if it works.
On Thursday, May 9, 2013 9:26:18 AM UTC-5, Mandeville, Rob wrote: > > I have (2) working in my own setup. It works well in Linux; you’ll have > to adjust the commands for other platforms. > > > > Make your first step in the build read GRAILS_HOME_VERSION and calculate > GRAILS_HOME. Then have it write that to a file. If you have set > GRAILS_HOME as an environment variable, the Linux command is: > > > > echo GRAILS_HOME=$GRAILS_HOME > /tmp/$BUILD_TAG.properties > > > > If you need to add any more lines to $BUILD_TAG.properties, use “>>” > instead of “>”. The “>” creates a new, empty file, and the “>>” appends to > it. > > > > Your next step is to inject environment variables, using the Properties > File Path of “/tmp/$BUILD_TAG.properties”. Now, everything you wrote to > $BUILD_TAG.properties are valid properties for the rest of the build. > > > > --Rob > > > > > > *From:* jenkins...@googlegroups.com <javascript:> [mailto: > jenkins...@googlegroups.com <javascript:>] *On Behalf Of *Bob Bick > *Sent:* Thursday, May 09, 2013 10:14 AM > *To:* 'Jerry'; jenkins...@googlegroups.com <javascript:> > *Subject:* RE: Newbie question - Setting environment variables on remote > node - EnvInject? > > > > Jerry, thanks for the response… > > > > I don’t think I made myself clear… Let me re-explain the situation… > > > > I realize that the EnvInject plugin is great for hard-coding environment > values that are *consistent* *across all Nodes *and *don’t vary from > build to build*. What I was trying to do is allow for environment > variables to (1) vary across nodes, and (2) vary from build to build. > > > > I have given up on requirement (2) because I don’t think the plugin > supports that. I have opted to use the file capability to support > requirement (1). > > > > Bob > > > > *From:* Jerry [mailto:gpj...@gmail.com <javascript:>] > *Sent:* Thursday, May 09, 2013 10:07 AM > *To:* jenkins...@googlegroups.com <javascript:> > *Cc:* Bob Bick > *Subject:* Re: Newbie question - Setting environment variables on remote > node - EnvInject? > > > > Hi, Bob. The EnvInject plugin would be perfect for this. You just select a > checkbox in the Build environment section labeled "Inject environment > variables to the build process", then specify a list of vars you want to > set: > GRAILS_HOME_1.2.3=c:\tools\grails-1.2.3 > SOME_OTHER_VAR=some.other.value > > It will be much easier than a Groovy script. However, I am not sure that > the latest version of the plugin (1.85) is working correctly. At least, I > am having trouble with it on a Windows build slave. In general, though, I > would recommend using EnvInject. > > -- Jerry > > > > On Wednesday, May 8, 2013 11:23:13 AM UTC-4, Bob Bick wrote: > > Hi, > > > > *Problem* > > I have an “Invoke top-level Maven target” Jenkins build step that invokes > Maven on a remote Jenkins node. Prior to invoking the Maven bat file on the > remote node, I’d like to inject a remote machine-specific environment > variable. > > > > Let me explain this in more detail… > > > > The Job will have a String parameter that defines the version > “GRAILS_HOME_VERSION”. Prior to starting the Job, the user will specify the > desired version (e.g. “2.2.1”). Each Jenkins node will define Grails home > versions Environment variables, such as: > > > > GRAILS_HOME_1.3.4=c:\tools\grails-1.3.4 > > GRAILS_HOME_2.1.1=c:\tools\grails-2.1.1 > > GRAILS_HOME_2.5=c:\tools\grails-2.5 > > > > Prior to invoking the “Invoke top-level Maven target” build step, I’d > like the GRAILS_HOME environment variable to be set based on the Job’s > “GRAILS_HOME_VERSION” and remote nodes GRAILS_HOME_X.Y.Z environment > variable. > > > > *Example 1. * > > Input>>> > > User sets Job’s GRAILS_HOME_VERSION= “2.1.1” > > Remote Node’s GRAILS_HOME_2.1.1=c:\tools\grails-2.1.1 > > > > Output>>> > > Set’s this variable prior to invoking “Invoke top-level Maven target” on > the remote node. > > GRAILS_HOME= c:\tools\grails-2.1.1 > > > > *Example 2. * > > Input>>> > > User sets Job’s GRAILS_HOME_VERSION= “1.2.3” > > Remote Node’s GRAILS_HOME_1.2.3=c:\tools\grails-1.2.3 > > > > Output>>> > > Set’s this variable prior to invoking “Invoke top-level Maven target” on > the remote node. > > GRAILS_HOME= c:\tools\grails-1.2.3 > > > > *Question* > > I am currently thinking to have a Groovy script provide the above based > functionality. However, I realize that the EnvInject plugin exists for > setting environment variables… > https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin > > > > Would someone provide guidance? I am having trouble figuring out how the > EnvInject plugin could help solve this problem… and it seems easy enough to > solve via groovy scripting. Can the EnvInject plugin work for this > situation? If so, any advice/examples would be appreciated! > > > > Thanks in advance, > > > > Bob > > > *** *** *** > This message contains information which may be confidential and > privileged. Unless you are the addressee (or authorized to receive for the > addressee), you may not use, copy or disclose to anyone the message or any > information contained in the message. If you have received the message in > error, please advise the sender by reply e-mail and delete the message. > > > *** *** *** > This message contains information which may be confidential and > privileged. Unless you are the addressee (or authorized to receive for the > addressee), you may not use, copy or disclose to anyone the message or any > information contained in the message. If you have received the message in > error, please advise the sender by reply e-mail and delete the message. > > -- > 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. > > > The information in this message is for the intended recipient(s) only > and may be the proprietary and/or confidential property of Litle & Co., > LLC, and thus protected from disclosure. If you are not the intended > recipient(s), or an employee or agent responsible for delivering this > message to the intended recipient, you are hereby notified that any use, > dissemination, distribution or copying of this communication is prohibited. > If you have received this communication in error, please notify Litle & Co. > immediately by replying to this message and then promptly deleting it and > your reply permanently from your computer. > -- 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.
