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

WorkingDir must match on every containerTemplate

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • kubernetes-plugin
    • None

      When setting different workingDir on each container Template.

      The «durable» script fail. It is referring to the first workingDir instead of the one for is container.

      A simple example that fail.

       

      podTemplate(label: 'mypod', containers: [
  containerTemplate(name: 'golang', image: 'golang:1.6.3', ttyEnabled: true, command: 'cat', workingDir:'/someworkingdir')
]) {
 node('mypod') {
   container('golang'){
     sh 'echo "POPO"'
   }
 }
}

      Will fail, since the default workingDir of the jnlp slave ('/home/jenkins') doesn't match with «/someworkingdir» on the golang containerTemplate.

       

      This same example, where the jnlp and golang workingDir match the same value, would work:

      podTemplate(label: 'mypod', containers: [
  containerTemplate(name: 'jnlp', image: 'jenkinsci/jnlp-slave:2.62-alpine', args: '${computer.jnlpmac} ${computer.name}', workingDir:'/someworkingdir'),
  containerTemplate(name: 'golang', image: 'golang:1.6.3', ttyEnabled: true, command: 'cat', workingDir:'/someworkingdir')
]) {
 node('mypod') {
   container('golang'){
     sh 'echo "POPO"'
   }
 }
}

       

          [JENKINS-44030] WorkingDir must match on every containerTemplate

          Carlos Sanchez added a comment -

          I think this is expected as the working dir is mounted across all containers in the same dir

          Carlos Sanchez added a comment - I think this is expected as the working dir is mounted across all containers in the same dir

          Pascal Laporte added a comment -

          If it is the case, it shouldn't be configurable at the container level, but at the pod level.

          Pascal Laporte added a comment - If it is the case, it shouldn't be configurable at the container level, but at the pod level.

          Scott Hebert added a comment -

          I recently hit this...

          With the sh step configured to return the exit code, the symptom is an error of "script returned exit code -2".
          With the sh step configured to return stdout, the symptom is something similar to this:

          Cannot contact some-slave2-bhq5k-m86b1: java.io.IOException: java.nio.file.NoSuchFileException: /tmp/workspace/my-container@tmp/durable-290e8fc7/output.txt

          Either we log a WARNING if we detect the use of a container workingDir, or we only allow configuration at the pod level.

          Scott Hebert added a comment - I recently hit this... With the sh step configured to return the exit code, the symptom is an error of "script returned exit code -2". With the sh step configured to return stdout, the symptom is something similar to this: Cannot contact some-slave2-bhq5k-m86b1: java.io.IOException: java.nio.file.NoSuchFileException: /tmp/workspace/my-container@tmp/durable-290e8fc7/output.txt Either we log a WARNING if we detect the use of a container workingDir, or we only allow configuration at the pod level.

          Nico Rikken added a comment -

          I encountered this issue with one (default) container with a set workingDir, and one pipeline specific container with no set workingDir in the template, but with a WORKDIR set in the Dockerfile used to build it. Making sure both are equal resolved the issue. Detecting mismatching working directories as a potential cause would have helped debugging this issue.

          Nico Rikken added a comment - I encountered this issue with one (default) container with a set workingDir, and one pipeline specific container with no set workingDir in the template, but with a WORKDIR set in the Dockerfile used to build it. Making sure both are equal resolved the issue. Detecting mismatching working directories as a potential cause would have helped debugging this issue.

          Allan BURDAJEWICZ added a comment -

          nicorikken This is solved since https://issues.jenkins.io/browse/JENKINS-58975 IIUC and one should be able to use a different workingDir for each container. But note that when overriding the workingDir of the jnlp container, all other containers are defaulted with the jnlp workingDir. In that case, the workingDir must be set for each container explicitely.

          Allan BURDAJEWICZ added a comment - nicorikken This is solved since https://issues.jenkins.io/browse/JENKINS-58975 IIUC and one should be able to use a different workingDir for each container. But note that when overriding the workingDir of the jnlp container, all other containers are defaulted with the jnlp workingDir . In that case, the workingDir must be set for each container explicitely.

          Nico Rikken added a comment -

          allan_burdajewicz Thanks for reporting back to me. This issue hasn't troubled me in 2020 if I remember correctly, so I guess I was on the 'happy flow' path again. But it feels good to know that there is now a way to fix this from Jenkins itself.

          Nico Rikken added a comment - allan_burdajewicz Thanks for reporting back to me. This issue hasn't troubled me in 2020 if I remember correctly, so I guess I was on the 'happy flow' path again. But it feels good to know that there is now a way to fix this from Jenkins itself.

            Unassigned Unassigned
            pascallap Pascal Laporte
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: