Details
-
Bug
-
Status: Resolved (View Workflow)
-
Critical
-
Resolution: Fixed
Description
The "dir('foo')" step inside "docker.image('my-image').inside" creates a directory "foo@tmp" instead of changing the current directory as expected.
In the test below, ">>> SHOULD LS THE foo DIR" is showing an "ls" is the parent dir instead of changing to the "foo" dir and we see a dir "foo@tmp" that have been created.
This problem is specific to "docker.image('my-image').inside", it does not happen with a standard "node".
docker.image('cloudbees/java-build-tools:0.0.7.1').inside { sh 'rm -rf foo*' // RE INIT TEST println '>>> LS THE PARENT DIR' sh 'mkdir -p foo/bar' sh 'ls -al' dir('foo') { println '>>> SHOULD LS THE foo DIR' sh 'ls -al' } }
Started by user admin
[Pipeline] Allocate node : Start
Running on jenkins-agent.beesshop.org in /home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4
[Pipeline] node {
[Pipeline] sh
[test-change-dir-4] Running shell script
+ docker inspect -f . cloudbees/java-build-tools:0.0.7.1
.
[Pipeline] Run build steps inside a Docker container : Start
$ docker run -t -d -u 1000:1000 -w /home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4 -v /home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4:/home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4:rw -v /home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4@tmp:/home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** cloudbees/java-build-tools:0.0.7.1 cat
[Pipeline] withDockerContainer {
[Pipeline] sh
[test-change-dir-4] Running shell script
+ rm -rf foo foo@tmp
[Pipeline] echo
>>> LS THE PARENT DIR
[Pipeline] sh
[test-change-dir-4] Running shell script
+ mkdir -p foo/bar
[Pipeline] sh
[test-change-dir-4] Running shell script
+ ls -al
total 12
drwxrwxr-x 3 jenkins jenkins 4096 Mar 13 21:50 .
drwxr-xr-x 4 root root 4096 Mar 13 21:50 ..
drwxr-xr-x 3 jenkins jenkins 4096 Mar 13 21:50 foo
[Pipeline] Change current directory : Start
Running in /home/ubuntu/jenkins-aws-home/workspace/tests/test-change-dir-4/foo
[Pipeline] dir {
[Pipeline] echo
>>> SHOULD LS THE foo DIR
[Pipeline] sh
[foo] Running shell script
+ ls -al
total 16
drwxrwxr-x 4 jenkins jenkins 4096 Mar 13 21:50 .
drwxr-xr-x 4 root root 4096 Mar 13 21:50 ..
drwxr-xr-x 3 jenkins jenkins 4096 Mar 13 21:50 foo
drwxrwxr-x 3 jenkins jenkins 4096 Mar 13 21:50 foo@tmp
[Pipeline] } //dir
[Pipeline] Change current directory : End
Attachments
Issue Links
- is blocked by
-
JENKINS-41474 docker.inside to rely on runC
-
- Open
-
- is blocking
-
-
- Closed
-
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
- relates to
-
JENKINS-38331 per stage agent directives
-
- Closed
-
-
-
- Resolved
-
- links to
Activity
docker exec doesn't allow to change the working directory and rejected proposal to introduce this feature, as exec is supposed to be a diagnostic-only tool.
so there's no non-hackish way to accomplish this.
For docker-slaves, ydubreuil created trampoline to change command working directory. As a standalone go binary, this one can be injected in the docker image using docker cp - yes, this is a hack, yet another.
| Field | Original Value | New Value |
|---|---|---|
| Summary | dir('foo') inside "docker.image().inside{}" creates "foo@tmp" instead of changing dir | dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes |
jglick it was unexpected to me but a folder "foo@tmp" was created. I can reproduce on a test environment if you want.
| Remote Link | This issue links to "PR 38 (Web Link)" [ 14075 ] |
a folder "foo@tmp" was created
Well that part is expected, if you are using a new durable-tasks.
Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java
src/test/java/org/jenkinsci/plugins/docker/workflow/WithContainerStepTest.java
http://jenkins-ci.org/commit/docker-workflow-plugin/e1a32fc5628ce2197f3ee447372e0a7782487e69
Log:
JENKINS-33510 At least clearly diagnose failure to set CWD.
Code changed in jenkins
User: Nicolas De loof
Path:
src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java
src/test/java/org/jenkinsci/plugins/docker/workflow/WithContainerStepTest.java
http://jenkins-ci.org/commit/docker-workflow-plugin/e07ea8d7625a42a892d6f05810e331c69ea8af9a
Log:
Merge pull request #38 from jglick/diag-pwd-JENKINS-33510
JENKINS-33510 At least clearly diagnose failure to set CWD
Compare: https://github.com/jenkinsci/docker-workflow-plugin/compare/d12dd885e89f...e07ea8d7625a
| Link |
This issue is blocking |
This has been annoying me of late. I would like to work with multiple checked out repos using docker.inside, but this makes it difficult
| Status | Open [ 1 ] | In Progress [ 3 ] |
jglick I see the PR 38 for this was merged - so a new release of docker pipeline will close this right?
| Link |
This issue is duplicated by |
This constellation:
docker.image('foo').inside {
node {
sh 'pwd'
}
fails for me too with:_
[ArangoDB_Devel_Build@2] Running shell script
JENKINS-33510: working directory will be /var/lib/jenkins/workspace/ArangoDB_Devel_Build not /var/lib/jenkins/workspace/ArangoDB_Devel_Build@2
sh: /var/lib/jenkins/workspace/ArangoDB_Devel_Build@2@tmp/durable-0b92a427/pid: No such file or directory
sh: /var/lib/jenkins/workspace/ArangoDB_Devel_Build@2@tmp/durable-0b92a427/jenkins-log.txt: No such file or directory
sh: /var/lib/jenkins/workspace/ArangoDB_Devel_Build@2@tmp/durable-0b92a427/jenkins-result.txt: No such file or directory_
I guess thats an artifact of this problem? is one discouraged to do that? Or will it be fixed?
| Workflow | JNJira [ 169439 ] | JNJira + In-Review [ 185700 ] |
| Component/s | pipeline-general [ 21692 ] |
| Component/s | workflow-plugin [ 18820 ] |
| Component/s | pipeline [ 21692 ] |
This had me scratching my head for a while. Glad to see there's a fix in progress.
Code changed in jenkins
User: tfennelly
Path:
Jenkinsfile
http://jenkins-ci.org/commit/blueocean-acceptance-test/e13cec063b8bcc45358ab0bda151ec280ac7bf77
Log:
Ok ... needed plugins update and also see JENKINS-33510 .... ffs
Code changed in jenkins
User: tfennelly
Path:
Jenkinsfile
http://jenkins-ci.org/commit/blueocean-acceptance-test/9960c382dd960de23c320392842e9959c49feb5f
Log:
Ok ... needed plugins update and also see JENKINS-33510 .... ffs
Given this is cataloged as a "Minor" issue, is there a workaround for this? This appears to render this plugin unusable from what I observe. My fairly simple script:
docker.image("...").inside("--args...") { sh "gradle build" }
can't get anywhere:
sh: /var/jenkins_home/workspace/job@tmp/durable-b85d7f08/pid: No such file or directory sh: /var/jenkins_home/workspace/job@tmp/durable-b85d7f08/jenkins-log.txt: No such file or directory sh: /var/jenkins_home/workspace/job@tmp/durable-b85d7f08/jenkins-result.txt: No such file or directory
Until there is a fix, a quick workaround is to prepend `cd foo &&` to each `sh` inside `dir('foo')`:
dir('foo') { sh 'cd foo && make' }
Abdulaziz Alfoudari
added a comment - - edited Until there is a fix, a quick workaround is to prepend `cd foo &&` to each `sh` inside `dir('foo')`:
dir( 'foo' ) {
sh 'cd foo && make'
}
I might have a different bug that has the same outcome but my script does not have any dir calls in it. With just a sh command I get this error.
Code changed in jenkins
User: Tom Fennelly
Path:
.printip.js
Dockerfile
Jenkinsfile
nightwatch.conf.js
package.json
run.sh
src/main/java/io/jenkins/blueocean/BOJUnitTest.java
src/main/java/io/jenkins/blueocean/BlueOceanWinstoneController.java
src/main/java/io/jenkins/blueocean/NightwatchRunner.java
src/main/js/custom_commands/moveClassicBottomStickyButtons.js
src/main/js/custom_commands/moveConfigpageButtons.js
src/main/js/custom_commands/removeBreadcrumbBar.js
src/main/js/custom_commands/removePageHead.js
src/main/js/globals.js
src/main/js/page_objects/blueocean/bluePipelineActivity.js
src/main/js/page_objects/classic_jenkins/folderCreate.js
src/main/js/page_objects/classic_jenkins/freestyleConfig.js
src/main/js/page_objects/classic_jenkins/freestyleCreate.js
src/main/js/page_objects/classic_jenkins/multibranchCreate.js
src/main/js/page_objects/classic_jenkins/pipelineCreate.js
src/main/nightwatch.json
src/test/java/utils/DevRunner.java
start-selenium.sh
stop-selenium.sh
http://jenkins-ci.org/commit/blueocean-acceptance-test/6aac5c09b5614833cb2bcd78bc346a7e4dd0c2da
Log:
More ATH shenanigans + a Jenkinsfile (#44)
- Added a simple Jenkinsfile
- Use docker-selenium images
- Use official images in the local start selenium scripts
- More tweaking of the Jenkinsfile
- And more tweaking of the Jenkinsfile again
- what's the pwd
- what's the pwd
- what's the pwd
- Map in a volume for ~/.m2
- Map in a volume for ~/.m2
- No clue what I'm doing
- revert BS tests
- please show me something
- dir doesn't work as you'd expect, it seems
- come on
- come on
- come on
- come on
- come on
- come on
- come on
- come on
- come on
- Ok ... needed plugins update and also see
JENKINS-33510.... ffs
- Trying to get it to build ... rest-impl tests hanging
- Changes to blueocean-ath-firefox
- Changes to blueocean-ath-builder
- Build BO and ATH on the executor
- Try get it working on executor
- Try get it working on executor
- Nope .... must build inside a docker container so as to get node etc
- Try and expose a port range
- Back to not building in a container
- Run the ATH
- Back to not running selenium
- printip
- printip
- printip
- printip
- printip
- printip
- printip
- printip
- Allow control of the http port used by the ATH Jenkins instance
- Can I see variables inside the docker image ...
- Allow spec of the blueocean host
- Start selenium in the Jenkinsfile and try connecting
- temp move build outside docker build container
- More jiggery pokery
- More jiggery pokery
- More jiggery pokery
- More jiggery pokery
- removed dead comment
- omg
- Fixed build of bo
- maven repo
- maven repo - more
- maven repo - more
- maven repo - more
- maven repo - more
- maven repo - more
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- use a local nexus repo
- local repo binding
- local repo binding
- getting closer
the secret .... run on linux
- print out the env
- What is setting the env grrr
- Fix jenkins_url file
- bind the port for the jenskins server
- Switch off selenium on the run script
- Switch off selenium on the run script
- Better messages on the start stop scripts
- Updated the local docker file
- Remove local .m2 binding
- Build the docker image for building
- See if it will work without an image name
- Nope ... didn't work
- Add docker label on node
- use mvn tool
- Can't run that node scrpit on a slave that already has an old node
- export the selenium server container IP address
- Connect using the docker bridge network
- sudo source
- Can't execute the script as source ... write IP to file
- Trim process.env.BLUEO_SELENIUM_SERVER_ADDR
- Try it on the CI Server
- Cleaned up messages from selenium-docker start scripts
- Use maven exit code for run script exit
- removed echo of exception as it was causing an NPE
- Trying to get the classic Jenkins pages working better
- Make the target dir if not already there
- Make moveClassicBottomStickyButtons complete more deterministic
- Fix moveClassicBottomStickyButtons to complete if used on a non-classic Jenkins page
- Remove the page head completely for classic Jenkins pages
- Fix activity page object "Open" toast selector
- Logging
- Cleanup move sticky buttons complete
- More cleanup of classic Jenkins page_object tweaks
- Get an env
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- try checkout of branch by the same name
- parameterise the branch name
- parameterise the branch name - some comments in the Jenkinsfile
- Output a message if we find a branch by that name
- Fix comment in Jenkinsfile
docwhat ha - no I think its just as this was referred to in a commit message in a pull request, and JIRA automatically picks it up (not directly related to this issue, but was impacted by it).
| Link | This issue is blocked by JENKINS-41474 [ JENKINS-41474 ] |
| Link |
This issue is related to |
Denis Boulas
made changes -
| Priority | Minor [ 4 ] | Critical [ 2 ] |
My ugly work arround with jenkins groovy libraries. I've made exec which make cd command before.
File : vars/exec.groovy
def call(String cmd, returnStdOut = false,returnStatus = false){
sh(script:"cd ${pwd()} && (${cmd})", returnStdout: returnStdOut,returnStatus: returnStatus)
}
Steve Todorov
added a comment - Is there any update on this issue? Using the purposed workarounds will not work in my case.
Steve Todorov
added a comment - Is there any update on this issue? Using the purposed workarounds will not work in my case. 
bitard michael
added a comment - pipeline {
agent {
docker {
image 'alpine:3.6'
label 'docker'
}
}
stages {
stage('in docker') {
steps {
sh 'ls && ps aux'
}
}
stage('outside docker') {
agent { label 'docker' }
steps {
sh 'ls && ps aux'
}
}
}
}
Here I have the simplest declarative pipeline possible, and the second stage fails with
JENKINS-33510: working directory will be [...]blah not [...]blah@2 sh: can't create [...]blah@2@tmp/durable-d763134e/pid: nonexistent directory sh: can't create [...]blah@2@tmp/durable-d763134e/jenkins-log.txt: nonexistent directory sh: can't create [...]blah@2@tmp/durable-d763134e/jenkins-result.txt: nonexistent directory
If that can help narrow the problem
bitard michael
added a comment -
pipeline {
agent {
docker {
image 'alpine:3.6'
label 'docker'
}
}
stages {
stage('in docker') {
steps {
sh 'ls && ps aux'
}
}
stage('outside docker') {
agent { label 'docker' }
steps {
sh 'ls && ps aux'
}
}
}
}
Here I have the simplest declarative pipeline possible, and the second stage fails with
JENKINS-33510: working directory will be [...]blah not [...]blah@2
sh: can't create [...]blah@2@tmp/durable-d763134e/pid: nonexistent directory
sh: can't create [...]blah@2@tmp/durable-d763134e/jenkins-log.txt: nonexistent directory
sh: can't create [...]blah@2@tmp/durable-d763134e/jenkins-result.txt: nonexistent directory
If that can help narrow the problem Unrelated—probably an unsupported image.
The cause is this issue is known, but no fix has been proposed.
| Status | In Progress [ 3 ] | Open [ 1 ] |
| Assignee | Jesse Glick [ jglick ] |
Michael Wu
added a comment - I have had the same issue, but I worked it around without using the `cd dir && ..` concatenated command. https://issues.jenkins-ci.org/browse/JENKINS-46636 If anyone is interested.
Michael Wu
added a comment - I have had the same issue, but I worked it around without using the `cd dir && ..` concatenated command. https://issues.jenkins-ci.org/browse/JENKINS-46636 If anyone is interested. jglick The Declarative example is same as the minimal reproduction of docker.image.inside with node inside the block given above.
Docker `exec` will eventually offer a `--workdir` option that would let us fix this
https://github.com/moby/moby/issues/8917#issuecomment-348299917
| Epic Link | JENKINS-47962 [ 186491 ] |
| Labels | cloudbees-internal-pipeline |
| Remote Link | This issue links to "CloudBees Internal CD-187 (Web Link)" [ 18949 ] |
cleclerc, jglick this issue has now been resolved in Docker - https://github.com/moby/moby/issues/8917. Could we expect this fixed in some of the upcoming releases of `docker-workflow-plugin` as well?
Steve Todorov
added a comment - - edited cleclerc , jglick this issue has now been resolved in Docker - https://github.com/moby/moby/issues/8917 . Could we expect this fixed in some of the upcoming releases of `docker-workflow-plugin` as well? abayer ndeloof I guess this means that new parameter could be used (once that version of docker is in circulation?)
Code changed in jenkins
User: Nicolas De Loof
Path:
src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java
src/test/java/org/jenkinsci/plugins/docker/workflow/WithContainerStepTest.java
http://jenkins-ci.org/commit/docker-workflow-plugin/983287324927b65d754174176c0c26ebdeffece9
Log:
[FIX JENKINS-33510] exec --workdir has been introduced in docker 17.12
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java
src/test/java/org/jenkinsci/plugins/docker/workflow/WithContainerStepTest.java
http://jenkins-ci.org/commit/docker-workflow-plugin/5aa1db202fd263e5bdc1cf2078c7258cb8e61bb0
Log:
Merge pull request #123 from ndeloof/JENKINS-33510
[FIX JENKINS-33510] exec --workdir has been introduced in docker 17.12
Compare: https://github.com/jenkinsci/docker-workflow-plugin/compare/ed5980955403...5aa1db202fd2
| Assignee | Nicolas De Loof [ ndeloof ] |
| Link |
This issue relates to |
I took the liberty to link JENKINS-38331 - per-stage `agent` declarations are also affected.
thanks weakcamel - they most certainly are as they are using docker pipeline under the covers at the moment.
This ticket is supposedly resolved... but then what do I need to write to make sure the `sh` commands are run in the correct working directory?
| Link |
This issue is duplicated by |
amcsi If you Docker Pipeline plugin is 1.15 and Docker is 17.12 or newer then everything should just work no need to change the Pipeline. That is if I understand the fix correctly.
duemir I have Docker Pipeline plugin 1.17, and Docker version 18.09.0. And doing dir in my Jenkinsfile got me...
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Run tests)
[Pipeline] dir
Running in /var/www
[Pipeline] {
[Pipeline] sh
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
$ docker stop --time=1 baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38
$ docker rm -f baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
GitHub has been notified of this commit’s build result
java.nio.file.AccessDeniedException: /var/www@tmp
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781)
at java.nio.file.Files.createDirectories(Files.java:767)
at hudson.FilePath.mkdirs(FilePath.java:3273)
at hudson.FilePath.access$1300(FilePath.java:213)
at hudson.FilePath$Mkdirs.invoke(FilePath.java:1254)
at hudson.FilePath$Mkdirs.invoke(FilePath.java:1250)
at hudson.FilePath.act(FilePath.java:1078)
at hudson.FilePath.act(FilePath.java:1061)
at hudson.FilePath.mkdirs(FilePath.java:1246)
at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController.<init>(FileMonitoringTask.java:174)
at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:200)
at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:192)
at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:110)
at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:99)
at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:278)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:270)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
at sun.reflect.GeneratedMethodAccessor312.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:129)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:129)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
at WorkflowScript.run(WorkflowScript:10)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
at com.cloudbees.groovy.cps.Next.step(Next.java:83)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:129)
at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:268)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$101(SandboxContinuable.java:34)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.lambda$run0$0(SandboxContinuable.java:59)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:58)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:182)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:332)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:83)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:244)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:232)
at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
amcsi So the defect indeed looks fixed and the issue appears to be with the file access now. Jenkins is trying to create a temp working directory besides the current working directory to write a shell script to but doesn't seem to have access to the `/var` directory. I would recommend reaching out to the mailing list or StackOverflow to get help with it if you have not yet solved it.
duemir oh, so it needs to create a directory like that as a sort of preparation.
But it doesn't make sense to me how it's expecting for the parent of the workdir to be writable.
I thought `/var/www` is fine for a workdir, but of course `/var` wouldn't be writable to the default user under normal circumstances. A popular article suggests to use `/app` as the workdir, where of course `/` wouldn't be writable. Why isn't Docker writing to `/var/tmp` instead which is writable? What am I (or others) expected to do instead?
amcsi dir with an absolute path is not supported inside a Docker container. Not really related to this issue. Simply start your sh script with cd. Or avoid using the withDockerContainer step alogether—if it works perfectly for you out of the box, great, otherwise forget about it.
| Link |
This issue relates to |
FYI, you need Docker Pipeline plugin v 1.15+ and Docker v 17.12+ in order to see this fix.
p cowlinator
added a comment - - edited FYI, you need Docker Pipeline plugin v 1.15+ and Docker v 17.12+ in order to see this fix. 
john dow
added a comment - I am still seeing this issue with Docker Pipeline v 1.22 and Docker v 19.03
Jenkinfile:
pipeline {
agent { docker {
image 'ruby'
args '-u root'
}
}
stages {
stage('build') {
steps {
sh '$PWD'
sh 'ruby --version'
}
}
}
I get the following error:
$ docker run -t -d -u 1000:996 -u root -w /var/jenkins_home/workspace/build-chef-pkgs --volumes-from 0d3a069ee976a6e027b7605d0b4d3abada6bcc9c1b1afcaf5ffa0610e4e83b76 -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 ******** ruby cat $ docker top c9b3ddcd8df5ea3e447f163006cd42a057ca55eea49f6df1c806d0e010459bfc -eo pid,comm [Pipeline] { [Pipeline] stage [Pipeline] { (build) [Pipeline] sh + /var/jenkins_home/workspace/build-chef-pkgs /var/jenkins_home/workspace/build-chef-pkgs@tmp/durable-e13f4856/script.sh: 1: /var/jenkins_home/workspace/build-chef-pkgs@tmp/durable-e13f4856/script.sh: /var/jenkins_home/workspace/build-chef-pkgs: Permission denied
The working directory is mounted as root and I cannot override the default user or working directory arguments passed to the docker run command
john dow
added a comment - I am still seeing this issue with Docker Pipeline v 1.22 and Docker v 19.03
Jenkinfile:
pipeline {
agent { docker {
image 'ruby'
args '-u root'
}
}
stages {
stage( 'build' ) {
steps {
sh '$PWD'
sh 'ruby --version'
}
}
}
I get the following error:
$ docker run -t -d -u 1000:996 -u root -w / var /jenkins_home/workspace/build-chef-pkgs --volumes-from 0d3a069ee976a6e027b7605d0b4d3abada6bcc9c1b1afcaf5ffa0610e4e83b76 -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 ******** ruby cat $ docker top c9b3ddcd8df5ea3e447f163006cd42a057ca55eea49f6df1c806d0e010459bfc -eo pid,comm [Pipeline] { [Pipeline] stage [Pipeline] { (build) [Pipeline] sh + / var /jenkins_home/workspace/build-chef-pkgs / var /jenkins_home/workspace/build-chef-pkgs@tmp/durable-e13f4856/script.sh: 1: / var /jenkins_home/workspace/build-chef-pkgs@tmp/durable-e13f4856/script.sh: / var /jenkins_home/workspace/build-chef-pkgs: Permission denied
The working directory is mounted as root and I cannot override the default user or working directory arguments passed to the docker run command jinzoo Have you given the example you wanted here? The Jenkinsfile you posted doesn't use dir () . Also, did you mean to use `sh "echo $PWD"` ?
Also, you did specify "-u root" in run args, which is exactly what you got.
It's not a blocker for us, we face this invoking packer and we workaround prefixing our sh 'packer ... 2>&1 | tee packer.log' call with a cd command, it looks like sh '(cd foo && packer ... 2>&1) | tee packer.log'.
cc asotobueno ndeloof