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]> [mailto:[email protected]] On Behalf Of Foxgang Sent: Thursday, May 09, 2013 11:39 AM To: [email protected]<mailto:[email protected]> Cc: 'Jerry'; [email protected]<mailto:[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]<javascript:> [mailto:[email protected]<javascript:>] On Behalf Of Bob Bick Sent: Thursday, May 09, 2013 10:14 AM To: 'Jerry'; [email protected]<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:[email protected]<javascript:>] Sent: Thursday, May 09, 2013 10:07 AM To: [email protected]<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 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.
