Ah yes, I didn't catch that distinction in OP's scenario. On Thursday, May 9, 2013 10:50:03 AM UTC-5, Mandeville, Rob wrote: > > Foxgang: I think you still need to create the properties file because > you are calculating the value within a build step. Even if you set an > environment variable within the step, that won’t export itself to the next > step of the job. > > > > Bob: I’m guessing that you’re running Windows (you mentioned a directory > starting with C:\ in your original post). The echo commands below probably > won’t work there. I’m not exactly sure how to generate a properties file > from the Windows command line, but if you’re a Windows shop, you’ll have > someone there that can. > > > > Can you check the contents of your properties file? Either the properties > file isn’t being generated correctly (in which case you need to fix your > script) or it simply isn’t being read by Jenkins (in which case I’ve never > run into that situation). > > > > --Rob > > > > > > *From:* Bob Bick [mailto:[email protected] <javascript:>] > *Sent:* Thursday, May 09, 2013 11:43 AM > *To:* [email protected] <javascript:> > *Cc:* 'Jerry'; Mandeville, Rob > *Subject:* RE: Newbie question - Setting environment variables on remote > node - EnvInject? > > > > It did not work for me… maybe I did something wrong? > > > > *From:* [email protected] <javascript:> [ > mailto:[email protected] <javascript:>] *On Behalf Of *Foxgang > *Sent:* Thursday, May 09, 2013 11:39 AM > *To:* [email protected] <javascript:> > *Cc:* 'Jerry'; [email protected] <javascript:> > *Subject:* Re: Newbie question - Setting environment variables on remote > node - EnvInject? > > > > 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:* [email protected] [mailto:[email protected]] *On > Behalf Of *Bob Bick > *Sent:* Thursday, May 09, 2013 10:14 AM > *To:* 'Jerry'; [email protected] > *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:[email protected]] > *Sent:* Thursday, May 09, 2013 10:07 AM > *To:* [email protected] > *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 > > > > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
