| I defined a Jenkins pipeline job with a Node parameter JENKINS_PARAM_RUN_NODE and the following script,
pipeline {
agent none
stages {
stage('Run') {
agent {
label "${env.JENKINS_PARAM_RUN_NODE}"
}
steps {
script {
echo 'Hello World'
sh 'export -p'
}
}
}
}
}
This showed JAVA_HOME of the Windows master despite selecting a MacOS agent.
...
+ export -p
...
export JAVA_HOME="C:\\Program Files\\Java\\jdk1.8.0_211"
Blanking the env variable exposes the MacOS agent's value,
environment {
JAVA_HOME = ''
}
...
+ export -p
...
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home"
As an added bonus unrelated to Jenkins, MacOS's /usr/bin/java seems to interpret the unexpected Windows notation in JAVA_HOME by selecting the latest installed (I suppose) java.home,
type -a java
java -version
jh=$(java -XshowSettings:properties 2>&1 | sed -ne 's/^[[:space:]]*java\.home = \(.*\)/\1/p')
echo "java.home=\"${jh}\""
+ type -a java
java is /usr/bin/java
+ java -version
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
++ java -XshowSettings:properties
++ sed -ne 's/^[[:space:]]*java\.home = \(.*\)/\1/p'
+ jh=/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home
+ echo 'java.home="/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home"'
java.home="/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home"
I do not expect JAVA_HOME of master to override the agent's environment. As for the blanking env var work-around, I am not sure if this agrees with the expected semantics of the "environment" DSL clause because instead of unsetting the variable, it appears to expose the agent's variable. |
