Using a `configFileProvider` within a `docker.inside {}` code block doesn't create the configuration file *in* the container but on *the host* running the container.

      node {
          docker.image('alpine').inside {
              configFileProvider([configFile(fileId: 'test-123', targetLocation: '/foobar')]) {
                  echo "In the container"
                  try {
                      sh "cat /foobar"
                  } catch (Exception exc) {
                      println exc
                  }
              }
          }
      
          echo "On the container"
          sh "cat /foobar"
      }
      

      Produces the following output:

      [Pipeline] Start of Pipeline
      [Pipeline] node
      Running on qemu2 in /home/jenkins/workspace/t-jenkins_bug-config-file-docker
      [Pipeline] {
      [Pipeline] withDockerServer
      [Pipeline] {
      [Pipeline] sh
      + docker inspect -f . alpine
      .
      [Pipeline] withDockerContainer
      qemu2 does not seem to be running inside a container
      $ docker run -t -d -u 0:0 -w /home/jenkins/workspace/t-jenkins_bug-config-file-docker -v /home/jenkins/workspace/t-jenkins_bug-config-file-docker:/home/jenkins/workspace/t-jenkins_bug-config-file-docker:rw,z -v /home/jenkins/workspace/t-jenkins_bug-config-file-docker@tmp:/home/jenkins/workspace/t-jenkins_bug-config-file-docker@tmp:rw,z -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** alpine cat
      $ docker top e4288736bfaaa9adb71e175384021ae505f1cab767b3ef4219783097b57ffb81 -eo pid,comm
      [Pipeline] {
      [Pipeline] configFileProvider
      provisioning config files...
      copy managed file [MyCustom] to file:/foobar
      [Pipeline] {
      [Pipeline] echo
      In the container
      [Pipeline] sh
      + cat /foobar
      cat: can't open '/foobar': No such file or directory
      [Pipeline] echo
      hudson.AbortException: script returned exit code 1
      [Pipeline] }
      [Pipeline] // configFileProvider
      [Pipeline] }
      $ docker stop --time=1 e4288736bfaaa9adb71e175384021ae505f1cab767b3ef4219783097b57ffb81
      $ docker rm -f e4288736bfaaa9adb71e175384021ae505f1cab767b3ef4219783097b57ffb81
      [Pipeline] // withDockerContainer
      [Pipeline] }
      [Pipeline] // withDockerServer
      [Pipeline] echo
      On the container
      [Pipeline] sh
      + cat /foobar
      123
      456[Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      

      (I have an additional withDockerServer around in this example, and Jenkins connects as root on the Docker host machine.)

          [JENKINS-58668] Doesn't create a file within docker.inside {}

          hmm, good catch - need to investigate to see how this is even doable...

          Dominik Bartholdi added a comment - hmm, good catch - need to investigate to see how this is even doable...

          Chad Gilbert added a comment -

          I've been using this plugin just fine inside docker containers. If targetLocation is set as relative to the workspace (e.g. "foobar" instead of "/foobar") then the file shows up as expected in the workspace, both inside and outside of the container.

          I'd argue that this use case should not be supported. If you really want to inject a config file outside of the shared workspace folder inside the container, you could subsequently move it out of the workspace folder inside the container.

          If anything, perhaps this plugin could issue a warning if targetLocation points to somewhere above the workspace directory.

          Chad Gilbert added a comment - I've been using this plugin just fine inside docker containers. If targetLocation is set as relative to the workspace (e.g. "foobar"  instead of "/foobar" ) then the file shows up as expected in the workspace, both inside and outside of the container. I'd argue that this use case should not be supported. If you really want to inject a config file outside of the shared workspace folder inside the container, you could subsequently move it out of the workspace folder inside the container. If anything, perhaps this plugin could issue a warning if targetLocation points to somewhere above the workspace directory.

          freakingawesome many thanks for the detailed explanation! I fully agree and therefore will resolve this issue

          Dominik Bartholdi added a comment - freakingawesome many thanks for the detailed explanation! I fully agree and therefore will resolve this issue

            domi Dominik Bartholdi
            multani Jonathan Ballet
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: