For Windows builds, use the build step "Run Windows batch file" and make it something like: echo GRAILS_HOME=%GRAILS_HOME% > %TEMP%\$BUILD_TAG.properties
You don't have to change the escape character on BUILD_TAG because it's a Jenkins variable, not a system variable. To confirm that this runs, just look on your build slave at %TEMP% and you should see a file named [something].properties. On Thu, May 9, 2013 at 11:50 AM, Mandeville, Rob <[email protected]>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]] > *Sent:* Thursday, May 09, 2013 11:43 AM > *To:* [email protected] > *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] [ > mailto:[email protected] <[email protected]>] > *On Behalf Of *Foxgang > *Sent:* Thursday, May 09, 2013 11:39 AM > *To:* [email protected] > *Cc:* 'Jerry'; [email protected] > *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.
