Passing Env System Variable to Jenkins Slave

It starts to drive me crazy .. but it seems to me that I was not lucky to figure it out: /

I need to configure a mechanism for sharing a string value between two slaves, for example, with the name slave A and slave B.

Currently, the closest I found is QUESTION: Updating Jenkins Slave environment variables

But it still aims to enable access in buildscripts, and not in the Slaves environment variable itself. (related SO question: How are environment variables used in Jenkins with a Windows command line? )

I currently have this setting:

1) task A starts on A.

It executes this Windows batch code (the actual paths are obviously 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-evident and straightforward imho.

2) Task A has upstream work B, which starts when the assembly is successful. So, in the subordinate B, B build executes this batch code (the actual paths are obviously 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 are taken from this SO request: Is there a command to update environment variables from the command line on Windows?


The output (% HOR_BUILD_ID% and% HOR_UPSTREAM_ID% values) is still deprecated ... the only way to update new variables is to restart the darn jenkins (master) service, but this definitely does not work in CI ...

Now the question arises: how to make these variables be updated / reread when the assembly task B starts in B , so I can access the system variables from the slave without using, for example, the EnvInject plugin?


Another question and answer that requires user interaction is therefore unacceptable in my case: Jenkins - passing variables between jobs?


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


Maybe the slave and its corresponding node do not receive the variable / resolve their environment to the kernel, which is why it is not possible to get the form of information Global variables envirtonemtn? Released it, and unexpectedly some interesting configuration data for the environment configuration echoed:

NODE_LABELS | realizes

NODE_NAME | a

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

I get the feeling that the problem with the root is that Jenkins has an error while resolving information with multiple subordinate nodes.

Solved by creating @Jenkins jira problem: https://issues.jenkins-ci.org/browse/JENKINS-15397

+6
source share
3 answers

Have you looked at adding a parameterized trigger plugin?

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

This will allow you to pass parameters from the first job to the second (for example, the name of the job to delete).

+2
source

I believe you are looking for Jenkins with parameterized builds! Follow the instructions here and you will be up and running anytime!

+2
source

It looks like this (https://issues.jenkins-ci.org/browse/JENKINS-6604) fixed the following changes:

  • fixed the inability to install more than one slave in a Windows 2k8 (R2) x64 (Datacenter) machine;
  • fixed inability to correctly resolve values. The setting has not been changed ... but it seems that re-enabling all the logins did the trick.
  • probobly violated the tool settings because NODE_LABELS and NODE_NAME are no longer loaded into the xD system information configuration ... but who cares while this setting works (and does not break into the next jenkins update ...): D

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

0
source

Source: https://habr.com/ru/post/926653/


All Articles