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

WorkingDir must match on every containerTemplate

    XMLWordPrintable

    Details

    • Similar Issues:

      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

            Hide
            csanchez Carlos Sanchez added a comment -

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

            Show
            csanchez Carlos Sanchez added a comment - I think this is expected as the working dir is mounted across all containers in the same dir
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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.
            Hide
            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.

            Show
            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.
            Hide
            allan_burdajewicz Allan BURDAJEWICZ added a comment -

            Nico Rikken 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.

            Show
            allan_burdajewicz Allan BURDAJEWICZ added a comment - Nico Rikken 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.
            Hide
            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.

            Show
            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

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

                Dates

                Created:
                Updated:
                Resolved: