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

Incorrect PATH over pipeline nodes

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Not A Defect
    • pipeline
    • None

    Description

      When having a pipeline task running over multiple nodes in sequence, the PATH environment is not reset when running on the next node. Here is a sample

      node('linux'){
          env.PATH = "${env.PATH}:/opt/myapp"
          echo "${env.PATH}"
      }
      node('windows'){
          env.PATH = "${env.PATH}:c:\\opt\\myapp"
          echo "${env.PATH}"
      }
      

      Output:

      [Pipeline] node
      Running on linux in /var/lib/jenkins/jobs/test-job/workspace
      [Pipeline] {
      [Pipeline] echo
      /sbin:/usr/sbin:/bin:/usr/bin:/opt/myapp
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] node
      Running on windows in c:/jenkins-slave/workspace/test-job
      [Pipeline] {
      [Pipeline] echo
      /sbin:/usr/sbin:/bin:/usr/bin:/opt/myapp:c:\opt\myapp
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      Finished: SUCCESS
      

      The PATH variable is wrong when it proceeds to the second (Windows) node.
      I'd expect the PATH to be whatever the Windows PATH is currently set to on the node, plus the extra path I wanted to inject.

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            Not really following, but sounds like a user list question.

            jglick Jesse Glick added a comment - Not really following, but sounds like a user list question.

            jglick Hey Jesse, I get that it's a no-no to try and modify the env global across multiple nodes. I'm curious what the expectations/best practices are for builds where we use multiple nodes and expect that the local env vars would be available within that node block scope.

            i.e. I start a build on a "generic" node which does the checkout, some initial setup and stashes the results, then fires off parallel branches to run on different OSes/platforms with that source. I'm seeing that the env vars sent down to sh calls are actually coming from the initial node the job started on, which was a little surprising. (I have env vars set to point to things like Android NDK/SDK install paths on boxes, etc. it feels odd to have to explicitly run a shell script to get the real value from the node and then pass that into a withEnv block.)

            seadub Chris Williams added a comment - jglick Hey Jesse, I get that it's a no-no to try and modify the env global across multiple nodes. I'm curious what the expectations/best practices are for builds where we use multiple nodes and expect that the local env vars would be available within that node block scope. i.e. I start a build on a "generic" node which does the checkout, some initial setup and stashes the results, then fires off parallel branches to run on different OSes/platforms with that source. I'm seeing that the env vars sent down to sh calls are actually coming from the initial node the job started on, which was a little surprising. (I have env vars set to point to things like Android NDK/SDK install paths on boxes, etc. it feels odd to have to explicitly run a shell script to get the real value from the node and then pass that into a withEnv block.)
            jglick Jesse Glick added a comment -

            As explained in the tutorial, do not modify env.ANYTHING_PLATFORM_SPECIFIC. Use the withEnv step instead.

            jglick Jesse Glick added a comment - As explained in the tutorial, do not modify env.ANYTHING_PLATFORM_SPECIFIC . Use the withEnv step instead.

            People

              jglick Jesse Glick
              trojanc Charl Thiem
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: