Newbie question - Setting environment variables on remote node - EnvInject?

[Bob Bick]

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.

[Jerry]

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

[Bob Bick]

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

[Mandeville, Rob]

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

--
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.
 
 

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.

[Bob Bick]

Good idea.

 

Thanks Rob

[Foxgang]

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. 

[Bob Bick]

It did not work for me… maybe I did something wrong?

[Mandeville, Rob]

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

[Jerry Maloney]

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.

[Foxgang]

Ah yes, I didn't catch that distinction in OP's scenario.