Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-19754

Jenkins/EnvInject incorrectly sets ${WORKSPACE} on slave node

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: envinject-plugin
    • Labels:
      None
    • Environment:
      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
    • Similar Issues:

      Description

      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

        Attachments

          Activity

          Hide
          ajbarber Andrew Barber added a comment -

          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.

          Show
          ajbarber Andrew Barber added a comment - 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.
          Hide
          ajbarber Andrew Barber added a comment -

          Lower priority since I have a work around.

          Show
          ajbarber Andrew Barber added a comment - Lower priority since I have a work around.
          Hide
          fluffy88 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

          Show
          fluffy88 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
          Hide
          btb3 Martin Ba added a comment -

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

          Show
          btb3 Martin Ba added a comment - 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 ...
          Hide
          aarondmarasco_vsi 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

          Show
          aarondmarasco_vsi 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
          Hide
          ajbarber Andrew Barber added a comment -

          After recent upgrades (jenkins 1.642.1, envinject 1.92.1), the work around has become intermittent. Every once a while system environment variables show up, including the improper WORKSPACE. This has become a real problem for us as there is no longer a work around.

          Show
          ajbarber Andrew Barber added a comment - After recent upgrades (jenkins 1.642.1, envinject 1.92.1), the work around has become intermittent. Every once a while system environment variables show up, including the improper WORKSPACE. This has become a real problem for us as there is no longer a work around.
          Hide
          intelradoux intelradoux added a comment -

          Hello,

          For other purpose (not this plugins) I created a "JOB_WORKSPACE" environment variable set to

          • /master/jobs/$JOB_NAME/workspace on master
          • /slave/workspace/$JOB_NAME on slaves

          When I use $JOB_WORKSPACE it is the correct parent path. Perhaps this can work with this plugins...

          Show
          intelradoux intelradoux added a comment - Hello, For other purpose (not this plugins) I created a "JOB_WORKSPACE" environment variable set to /master/jobs/$JOB_NAME/workspace on master /slave/workspace/$JOB_NAME on slaves When I use $JOB_WORKSPACE it is the correct parent path. Perhaps this can work with this plugins...
          Hide
          barnish Andrew Barnish added a comment -

          We are still seeing this issue with jenkins 2.138 and envinject 2.16, although the workaround suggested above still seems to work.

          Does anyone know how to fix it properly?

          Show
          barnish Andrew Barnish added a comment - We are still seeing this issue with jenkins 2.138 and envinject 2.16, although the workaround suggested above still seems to work. Does anyone know how to fix it properly?

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              ajbarber Andrew Barber
            • Votes:
              5 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: