Jenkins Docker Pipeline override working directory

Question

I have noticed when using Jenkins with the Docker Pipeline plugin. When I create a Jenkins file to run commands in a docker container that it always creates a volume mapping of the Jenkins workspace directory mapped to the same path in the running container. It also creates a working directory with the same path.

docker run -t -d -u 127:134 -w /var/lib/jenkins/workspace/DockerTest 
-v /var/lib/jenkins/workspace/DockerTest:/var/lib/jenkins/workspace/DockerTest:rw,z 
-v /var/lib/jenkins/workspace/DockerTest@tmp:/var/lib/jenkins/workspace/DockerTest@tmp:rw,z 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
jekyll/jekyll:builder cat

I tried to override this by providing arguments in my Jenkinsfile for Docker like this:

pipeline {
  agent {
    docker {
      image 'jekyll/jekyll:builder'
      args '-v $HOME:/srv/jekyll -w /srv/jekyll'
    }
  }
  stages {
    stage('Test') {
      steps {
      sh 'cd /srv/jekyll && ls -l'
      }
    }
  }
}

It seems that this just prepends the options to the Docker command and the workdir and volume mapping gets overwritten by the default settings:

docker run -t -d -u 127:134 
-v $HOME:/srv/jekyll 
-w /srv/jekyll 
-w /var/lib/jenkins/workspace/DockerTest 
-v /var/lib/jenkins/workspace/DockerTest:/var/lib/jenkins/workspace/DockerTest:rw,z 
-v /var/lib/jenkins/workspace/DockerTest@tmp:/var/lib/jenkins/workspace/DockerTest@tmp:rw,z 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
-e ******** 
jekyll/jekyll:builder cat

Is there any way that I can override the volume mappings and working directory in any way?

Solution 1

You can combine docker {} with dir {} to control the working directory:

pipeline {
  agent {
    docker {
      image 'jekyll/jekyll:builder'
      args '-v $HOME:/srv/jekyll'
    }
  }
  stages {
    stage('Test') {
      steps {
        dir(path: '/srv/jekyll') {
          sh 'ls -l'
        }
      }
    }
  }
}

I've dropped the -w argument, since it has no effect, and replaced cd /src/jekyll with dir(path: '/srv/jekyll'){...}

Solution 2

we had a same requirement to use work directory different than the default one in container, after checking it understood as of now its not possible. check here for more details JENKINS-41474, JENKINS-35406, JENKINS-33510

the other way is to use dir("path_to_work") { sh ' '}, but it did not worked either. so only way is to mount the volume in container with args and run all the commands with change directory command in it

  pipeline {
  agent {
    docker {
      image 'alpine:3.7'
      args '-v $HOME/src:/src'
    }
  }
  stages {
    stage('Build') {
      steps {
      sh 'cd /src ; ./run_build.sh'
      }
    }
  }
}

Solution 3

@Nagri unfortunately I could still not specify the working directory and volume mapping.

But I could run jekylll as root.

It is not ideal but at least it works.

    pipeline {
        agent {
            docker {
                image 'jekyll/jekyll:builder'
                args '-u root'
            }
        }
        stages {
            stage('Test') {
                steps {
                    sh 'mkdir -p _site'
                    sh 'jekyll build'
                }
            }
        }
    }

Comments

[Nagri]

@julianlab Did you find the solution? I am facing the same issue.

[Reddysekhar Gaduputi]

when using dir(path: '/src'), pipeline is failing with below. is there anything else can be done to fix this ? process apparently never started in /src@tmp/durable-234fa142

[Krzysztof Krzeszewski]

it says that there is java.nio.file.AccessDeniedException any ideas how to fix it?

[tuxErrante]

What if you want that directory to be created at runtime? The goal is to let concurrent builds not to override each other's files.