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

Image.inside overrides working directory

XMLWordPrintable

      Image.inside automatically sets up volumes and a workdir. Its impossible to override this workdir. Ideally workdir should not be touched at all IMO but at the very least it should be overridable.

      When using a command like this:

      build.inside('-w /usr/src/app/') {
  sh 'npm run lint'
}

      You'll get output like this

      [Pipeline] withDockerContainer
$ docker run -t -d -u 1002:1002 -w /usr/src/app/ -w /home/*******/workspace/*******/development -v /home/*******/workspace/*******/development:/home/*******/workspace/*******/development:rw -v /home/*******/workspace/*******/development@tmp:/home/*******/workspace/*******/development@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** *******:5000/*******/*******:11-feature

      You can see that the `-w` option is passed to the command but since the plugin forces `-w` /path/to/jenkins/workspace no matter what their is no way around this outside `cd /workdir` inside every inside command.

          [JENKINS-35406] Image.inside overrides working directory

          Jesse Glick added a comment -

          You would use JENKINS-33510, if that worked. For now, use cd.

          Jesse Glick added a comment - You would use JENKINS-33510 , if that worked. For now, use cd .

          Axel Heider added a comment -

          Sadly, it seems this issues still exists. I'm proposing to re-open it that is is addresses. It remains unclear, why this is enforced. Docker allows nicely isolating this from any host environment, so why does Jenkins (or the plugin) insist on bringing thing knowledge in?

          Axel Heider added a comment - Sadly, it seems this issues still exists. I'm proposing to re-open it that is is addresses. It remains unclear, why this is enforced. Docker allows nicely isolating this from any host environment, so why does Jenkins (or the plugin) insist on bringing thing knowledge in?

          Raphael added a comment - - edited

          I agree, this is still a problem: for me, it breaks parallel stages unstash-ing the same Python venv (which isn't supposed to be moved, for some reason) at different container-paths.

          (I'm doing agent { docker

          { ... }

          } in a declarative pipeline, which I assume uses the same implementation?)

          That one is still open: JENKINS-61743

          Raphael added a comment - - edited I agree, this is still a problem: for me, it breaks parallel stages unstash -ing the same Python venv (which isn't supposed to be moved, for some reason) at different container-paths. (I'm doing agent { docker { ... } } in a declarative pipeline, which I assume uses the same implementation?) That one is still open: JENKINS-61743

            jglick Jesse Glick
            nitropye Coleman
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: