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

WorkingDir must match on every containerTemplate

    XMLWordPrintable

Details

    Description

      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"'
         }
       }
      }
      

       

      Attachments

        Issue Links

          Activity

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

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

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

            pascallap Pascal Laporte added a comment - If it is the case, it shouldn't be configurable at the container level, but at the pod level.
            scoheb 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.

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

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

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

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: