Passing System Env variable into Jenkins Slave

Question

This is starting to drive me crazy .. but it seems like I am out of luck to figure it out by myself :/

I need to set up a mechanism to share string value between two slaves, for example, named slave A and slave B.

Currently most closest one I have found is this SO Question: Jenkins Slave Environment Variable Refresh

But it still aims to enable access in buildscripts, not in the Slaves environment variable itself. (related SO Question: How are environment variables used in Jenkins with Windows Batch Command?)

Currently I have this setup:

1) on A the job A is triggered.

It performs this windows batch code (actual paths, obviously, are replaced with '<>'):

cmd /c start java -jar <path_of_slave>\slave.jar -jnlpUrl  <url_of_slave>/slave-agent.jnlp

setenv.exe /m HOR_BUILD_ID -delete
setenv.exe /m HOR_BUILD_ID %BUILD_NUMBER%
setenv.exe /m HOR_UPSTREAM_ID -delete
setenv.exe /m HOR_UPSTREAM_ID %JOB_NAME%

Pretty self-explanatory and straight-forward imho.

2) The job on A have upstream job B, that is triggered on successful build. So, in the slave B the B build executes this batch code(actual paths, obviously, are replaced with '<>'):

SetLocal EnableDelayedExpansion

@echo off
@echo --- Refreshing Environemnt variables... 
@echo on
set prgfil=%ProgramFiles(x86)%
call "%WORKSPACE%\..\..\..\tools\misc\resetvars.bat"
@echo --- Reading environment variables... 
copy /y "<path_containing_%HOR_UPSTREAM_ID%_variable" "<path_containing_%HOR_BUILD_ID%_variable"
if !errorlevel!==0 goto ok1
goto error
:ok1

goto end

:error
EndLocal
exit /b 1

:end
EndLocal

NOTE: resetvars.bat and resetvars.vbs is taken from this SO Question: Is there a command to refresh environment variables from the command prompt in Windows?

---

The output (%HOR_BUILD_ID% and %HOR_UPSTREAM_ID% values), still, is outdated ... only way to get new variables refreshed is to restart that darn jenkins (master) service, but this is definetly no-go in the CI environment...

The question now surfaces - how to make those variables to be refreshed / re-read when the build job B on B is triggered, so I could access system variables from slave w/o using, for example, EnvInject plugin?

---

Another SO Question and answer that needs user interaction, therefore not acceptable in my case: Jenkins - passing variables between jobs?

---

This also do not work in my case: http://comments.gmane.org/gmane.comp.java.hudson.user/37897

---

Maybe the Slave and its coresponding node do not recieve variable / resolve its environment coreectly, causing to be unable to retrieve information form Global envirtonemtn variables? Cechked it out and suddenly some interesting Environment variable config data cought my eye:

NODE_LABELS | a prodreleases

NODE_NAME | a

... this is for slave B , but it should be different values as this is originally for slave A ... What a hell??????????????????!!!! :/

I am starting to have feeling that root problem is that Jenkins has bug when resolving multiple slave NODE information.

Decided to create a Issue @ Jenkins jira: https://issues.jenkins-ci.org/browse/JENKINS-15397

Informed

Hey mate, I couldn't understand everything you wrote. But basically I did able to pass Jenkins System Variable via ant script. – Generalship

that is too much bloat and java parsing horsepower for such basic need. :/ – Informed

I would avoid passing data between slaves via Jenkins script/job - this is likely to break when adding slaves or taking a slave offline. Chaining the jobs (as suggested by @zagrev ) is a much better way, you can then pass the data in an artifact or use a plugin. – Sforza

Answer 1

Have you looked at adding parameterized trigger plugin?

https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

This should allow you to pass parameters from the first job to the second (like the job name to delete).

Chesterton

What I need is to read a SYSTEM env variable ( in the Machine context ) INTO BATCH of Job B <- FROM <- SYSTEM env variable ( in the Machine context ), that I set as SYSTEM env variable ( in the Machine context ) in Job A. Currently nothing allows me to do that. – Informed

So, java doesn't let you write system variables back out to the OS. Jenkins is run on java, so you probably cannot write OS environment variables. Sounds like you need to choose a different method of communication between the jobs. If Job A actually writes out an OS environment variable, then it will be picked up by the JVM in Job B. Have you thought of using files to contain the information, or maybe messages from a queue? shared memory? Do you have the ability to change how Job A passes the data? – Chesterton

Files - no, I am using this for some VM managament, so I cannot use static file location / storage. Message Queue ... in detail, please. :) Jes, I have full control of Jenkins. – Informed

Those details depend on the messaging system you are using. Reviewing the original post, should it not be calling setenv.exe THEN starting the slave? – Chesterton

Also, can you try the Environment Inject plugin? – Chesterton

I did take a look, but I (if) undrestood (correctly) from wiki the plugin uses (basically) java-prop based injection, not direct inject from OS, so it generally is another no-go... (+1 for suggestion though) – Informed

After another rabling tour I finally managed to send those params to other slaves nodes job. But here it was done by no using as Post-Byuild step, but launching the other job as Subproject usign the plugin. This way the variables are set and sent and useg as expected. Thank you all for help. Accepting this answer. – Informed

Answer 2

Seems like this (https://issues.jenkins-ci.org/browse/JENKINS-6604) fix made the the following changes:

• fixed inpossibility to install more than one slave in Windows 2k8 (R2) x64 (Datacenter) machine ;
• fixed inpossibility to correctly resolve values. The setup was not changed ... but it seems like reentering all the logins did the trick.
• probobly broke the Tool Environemnt settings as the NODE_LABELS and NODE_NAME is not loaded in System Information config anymore xD ... but who cares as long as this setup actually works ( and is not broken in next jenkins update ... ) :D

For reference, the jira issue I created is still open ...

Informed