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

node / dir / node on same agent sets PWD to that of dir rather than @2 workspace

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • Jenkins: 2.346.3
      OS: Linux - 4.14.203-156.332.amzn2.x86_64
      workflow-durable-task-step:1217.v38306d8fa_b_5c

      I thought I saw this fixed in 1210.va_1e5d77e122b
      but we are hitting it in 1217.v38306d8fa_b_5c
       
      We hit this in one of our libraries, and were able to refactor around it. I've attached our Jenkins info, and our minimal Jenkinsfile reproduction.
       
      From our console output, I distilled what we were seeing on our AWS node agent.
       

      "start workspace : workspace is /home/ec2-user/workspace/enkins-reproworkspacebug2_master
      to dir() : /home/ec2-user/workspace/enkins-reproworkspacebug2_master/vars
      to new node() and workspace : workspace is /home/ec2-user/workspace/enkins-reproworkspacebug2_master__2
      BUT cwd() is old workspace/dir : /home/ec2-user/workspace/enkins-reproworkspacebug2_master/vars"

      This looks related to https://issues.jenkins.io/browse/JENKINS-69936 but it does not seem like it was fixed for us? Or perhaps it is subtly different.

          [JENKINS-70528] node / dir / node on same agent sets PWD to that of dir rather than @2 workspace

          Matt added a comment -

          It should be noted that if the node() call was to a different host, we would not see this issue. The issue was that if we node() to the same host (either by accident, or label maps to the same), we DO get a new WORKSPACE, but we DON'T get a correct cwd()

          Matt added a comment - It should be noted that if the node() call was to a different host, we would not see this issue. The issue was that if we node() to the same host (either by accident, or label maps to the same), we DO get a new WORKSPACE, but we DON'T get a correct cwd()

          Jesse Glick added a comment -

          Reproduced this situation in a test. Not sure yet whether it is practical to fix.

          (Generally speaking, running a node block inside another node block is a bad idea, and if you were doing so merely because some library function is unsure whether or not it was called from code within a node block, you can check env.NODE_NAME == null before starting a new one.)

          Jesse Glick added a comment - Reproduced this situation in a test. Not sure yet whether it is practical to fix. (Generally speaking, running a node block inside another node block is a bad idea, and if you were doing so merely because some library function is unsure whether or not it was called from code within a node block, you can check env.NODE_NAME == null before starting a new one.)

          Jesse Glick added a comment -

          (Please update to https://github.com/jenkinsci/workflow-basic-steps-plugin/releases/tag/1010.vf7a_b_98e847c1 which will pull in the fix in workflow-durable-task-step; unfortunately the reverse is not true and you would be left with some harmless warnings in your builds.)

          Jesse Glick added a comment - (Please update to https://github.com/jenkinsci/workflow-basic-steps-plugin/releases/tag/1010.vf7a_b_98e847c1 which will pull in the fix in workflow-durable-task-step ; unfortunately the reverse is not true and you would be left with some harmless warnings in your builds.)

            jglick Jesse Glick
            hallm Matt
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: