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

running linux type dockerNode under windows node section causes failure due to workspace ambiguity

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • docker-plugin
    • jenkins 2.249.1
      docker plugin 1.2.1

      we have to following code:

      node(some_windows_machine_label)
      {
         dockerNode('some_linux_image')
         {
             // here we perform git checkout using the checkout method.
         }
      }
      
      

      running the above code using version 1.2.0 of docker plugin works fine, and running it using the new version (1.2.1) fails due to some workspace ambiguity (suddenly the dockerNode is aware of the windows node workspace..

       

      moving the dockerNode section outside the node section works perfectly, but it costs us a lot to change all the scripts we already have...

      I'll try to provide logs with the error.

      I don't see any reason for this change of behavior...

       

          [JENKINS-63824] running linux type dockerNode under windows node section causes failure due to workspace ambiguity

          pjdarton added a comment -

          That is peculiar. There haven't been any deliberate changes to dockerNode functionality for many years.
          I've taken a look through all the code changes between 1.2.0 and 1.2.1 and there isn't really anything that stands out as an obvious cause.

          The enhancements to the docker-attach method might be to blame, but I was reasonably sure that code defaults to how things always used to work (there was never any intent to break things).
          I would suggest that you run a docker inspect command against a working container (one started by version 1.2.0) and a non-working one (one started by version 1.2.1) and see where the differences lie; that ought to reveal any undesired changes to how the containers are being run, as if there were unintentional changes they'll show up that way.

          If not, I'd suggest you pick through the code changes and see if you can find anything that stands out as worthy of further investigation.

          pjdarton added a comment - That is peculiar. There haven't been any deliberate changes to dockerNode functionality for many years. I've taken a look through all the code changes between 1.2.0 and 1.2.1 and there isn't really anything that stands out as an obvious cause. The enhancements to the docker-attach method might be to blame, but I was reasonably sure that code defaults to how things always used to work (there was never any intent to break things). I would suggest that you run a docker inspect command against a working container (one started by version 1.2.0) and a non-working one (one started by version 1.2.1) and see where the differences lie; that ought to reveal any undesired changes to how the containers are being run, as if there were unintentional changes they'll show up that way. If not, I'd suggest you pick through the code changes and see if you can find anything that stands out as worthy of further investigation.

            Unassigned Unassigned
            amidar Amit Dar
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: