-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Linux 2.6.40-3.0.9 #9 SMP Tue Sep 11 09:59:55 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux
EnvInjectPlugin 1.88
When a jobs is launched on a slave, ${WORKSPACE} is set to the slave root instead of the workspace directory when EnvInject is enabled (default settings in this case). I setup a simple example with a project that does
echo ${WORKSPACE}
pwd
The project is a basic project (named Test-Slave) - the only selection changed from the default is "Restrict where this project can be run" which I set to my slave. Here is the console for the job. You can see the difference between ${WORKSPACE} and pwd.
[EnvInject] - Loading node environment variables.
Building remotely on XL-build1 in workspace /home/scratch/jenkins_xl/workspace/Test-Slave
[Test-Slave] $ /bin/sh -xe /tmp/hudson4075547965590808000.sh
+ echo /home/scratch/jenkins_xl
/home/scratch/jenkins_xl
+ pwd
/home/scratch/jenkins_xl/workspace/Test-Slave
[JENKINS-19754] Jenkins/EnvInject incorrectly sets ${WORKSPACE} on slave node
Andrew Barber
created issue -
Andrew Barber
made changes -
| Component/s | New: envinject [ 15893 ] | |
| Component/s | Original: slave-setup [ 15929 ] | |
| Assignee | Original: Kohsuke Kawaguchi [ kohsuke ] | New: Gregory Boissinot [ gbois ] |
| Description |
Original:
When a jobs is launched on a slave, ${WORKSPACE} is set to the slave root instead of the workspace directory. I setup a simple example with a project that does echo ${WORKSPACE} pwd The project is a basic project - the only selection changed from the default is "Restrict where this project can be run" which I set to my slave. Here is the console for the job. You can see the difference between ${WORKSPACE} and pwd. [EnvInject] - Loading node environment variables. Building remotely on XL-build1 in workspace /home/scratch/jenkins_xl/workspace/Test-Slave [Test-Slave] $ /bin/sh -xe /tmp/hudson4075547965590808000.sh + echo /home/scratch/jenkins_xl /home/scratch/jenkins_xl + pwd /home/scratch/jenkins_xl/workspace/Test-Slave |
New:
When a jobs is launched on a slave, ${WORKSPACE} is set to the slave root instead of the workspace directory when EnvInject is enabled (default settings in this case). I setup a simple example with a project that does echo ${WORKSPACE} pwd The project is a basic project (named Test-Slave) - the only selection changed from the default is "Restrict where this project can be run" which I set to my slave. Here is the console for the job. You can see the difference between ${WORKSPACE} and pwd. [EnvInject] - Loading node environment variables. Building remotely on XL-build1 in workspace /home/scratch/jenkins_xl/workspace/Test-Slave [Test-Slave] $ /bin/sh -xe /tmp/hudson4075547965590808000.sh + echo /home/scratch/jenkins_xl /home/scratch/jenkins_xl + pwd /home/scratch/jenkins_xl/workspace/Test-Slave |
| Priority | Original: Major [ 3 ] | New: Critical [ 2 ] |
Andrew Barber
made changes -
| Summary | Original: Jenkins incorrectly sets ${WORKSPACE} on slave node | New: Jenkins/EnvInject incorrectly sets ${WORKSPACE} on slave node |
Andrew Barber
made changes -
| Environment | Original: Linux 2.6.40-3.0.9 #9 SMP Tue Sep 11 09:59:55 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux |
New:
Linux 2.6.40-3.0.9 #9 SMP Tue Sep 11 09:59:55 PDT 2012 x86_64 x86_64 x86_64 GNU/Linux EnvInjectPlugin 1.88 |
Andrew Barber
added a comment - Lower priority since I have a work around. Andrew Barber
made changes -
| Priority | Original: Critical [ 2 ] | New: Major [ 3 ] |
I have noticed this same issue.
My ${WORKSPACE} variable is set to the slave FS root since I've installed the EnvInject plugin.
However when trying Andrew's workaround it doesn't seem to work for me.
Jenkins version: 1.532.3
Environment Injector Plugin version: 1.89
Seán Dunne
added a comment - - edited I have noticed this same issue.
My ${WORKSPACE} variable is set to the slave FS root since I've installed the EnvInject plugin.
However when trying Andrew's workaround it doesn't seem to work for me.
Jenkins version: 1.532.3
Environment Injector Plugin version: 1.89 I cannot see this on Windows. (Jenkins 1.480.3 + EnvInject plugin 1.83)
So maybe it is Linux specific or doesn't happen in my old version ...
Aaron D. Marasco
added a comment - I hit this bug as well with Jenkins 1.634 and EnvInject 1.92.1. The workaround above worked for me as well.
Before workaround, slave's "root" workspace used:
Building remotely on xilinx_builder (x86_64 hdlbuilder-ml605) in workspace /data/jenkins_workspace_xilinx_1/workspace/build_hdl
+ env
+ sort
WORKSPACE=/data/jenkins_workspace_xilinx_1
After:
Building remotely on xilinx_builder (x86_64 hdlbuilder-ml605) in workspace /data/jenkins_workspace_xilinx_1/workspace/build_hdl
+ env
+ sort
WORKSPACE=/data/jenkins_workspace_xilinx_1/workspace/build_hdl
Aaron D. Marasco
added a comment - I hit this bug as well with Jenkins 1.634 and EnvInject 1.92.1. The workaround above worked for me as well.
Before workaround, slave's "root" workspace used:
Building remotely on xilinx_builder (x86_64 hdlbuilder-ml605) in workspace /data/jenkins_workspace_xilinx_1/workspace/build_hdl
+ env
+ sort
WORKSPACE=/data/jenkins_workspace_xilinx_1
After:
Building remotely on xilinx_builder (x86_64 hdlbuilder-ml605) in workspace /data/jenkins_workspace_xilinx_1/workspace/build_hdl
+ env
+ sort
WORKSPACE=/data/jenkins_workspace_xilinx_1/workspace/build_hdl 
Upgraded to jenkins 1.534, still same issue. I have a workaround now though.
○ Select "Prepare jobs environment" on the slave
○ Select "Unset System Environment Variables" on the slave
Both of these must be set and the ${WORKSPACE} appears correctly. I would think that unsetting system variables would lead to ${WORKSPACE} issues instead of fixing it.
Either way, I think ${WORKSPACE} should be correct regardless of these settings.