导致docker容器退出的Jenkins pipeline dir()指令

导致docker容器退出的Jenkins pipeline dir()指令,docker,jenkins,jenkins-pipeline,Docker,Jenkins,Jenkins Pipeline,以下是我在这一问题上提出的问题: 我成功地以root用户的身份运行了容器,但是我收到的实际java堆栈跟踪失败保持不变——这意味着这不是容器中用户的权限错误 实际问题似乎与my stage中的dir(){}步骤有关。若要重新迭代,请执行以下操作: steps { dir('/src') { sh 'pwd' // any command } } steps { sh 'cd /src && pwd' } 容器将在不运行命令的情况下退出

以下是我在这一问题上提出的问题:

我成功地以root用户的身份运行了容器,但是我收到的实际java堆栈跟踪失败保持不变——这意味着这不是容器中用户的权限错误

实际问题似乎与my stage中的
dir(){}
步骤有关。若要重新迭代,请执行以下操作:

steps {
    dir('/src') {
        sh 'pwd'  // any command
    }
}
steps {
    sh 'cd /src && pwd'
}
容器将在不运行命令的情况下退出:

[Pipeline] withDockerContainer
Jenkins seems to be running inside container aaee62f2a28e29b94c13fcdc08c1a82ef7baed48beabe54579db07b2fbd26b23
$ docker run -t -d -u 1000:1000 -w "/var/jenkins_home/workspace/My Project" --volumes-from aaee62f2a28e29b94c13fcdc08c1a82ef7baed48beabe54579db07b2fbd26b23 -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 ******** 12724611f0bf2363c9eee7288654e43eca2aabaf cat
$ docker top 4e29bc102d8f4e6b4ffc142fc06eb706e95b00fa6190b2927f4f79f0cfa53af5 -eo pid,comm
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] dir
Running in /src
[Pipeline] {
[Pipeline] sh
[Pipeline] }
[Pipeline] // dir
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
$ docker stop --time=1 4e29bc102d8f4e6b4ffc142fc06eb706e95b00fa6190b2927f4f79f0cfa53af5
$ docker rm -f 4e29bc102d8f4e6b4ffc142fc06eb706e95b00fa6190b2927f4f79f0cfa53af5
生成结束时的故障堆栈跟踪为:

java.nio.file.AccessDeniedException: /src
    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:181)
    at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:221)
    at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:210)
    at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:131)
    at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:99)
    at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:305)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:268)
    at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:176)
    at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    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:23)
    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.GeneratedMethodAccessor143.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:136)
    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

该命令按预期运行。这是Jenkins内部的错误还是我误解了dir()指令的用途?

一般来说,
dir()指令的目的是将当前工作目录更改为Jenkins代理上运行构建本身的另一个目录

具体来说,docker插件方面有一个限制,如下所述:

Docker容器内不支持具有绝对路径的
dir
。只需用
cd
启动
sh
脚本即可。或者避免在DockerContainer中使用
单步操作-如果它完全适合你,那就开箱即用,太好了,否则就忘了它


因此,如果我们认为您当前的解决方法是一种解决方法,那么您当前的解决方法是推荐的。

我同意这是一个bug。并在这里报道了这一问题: 核心维护人员似乎觉得实际上没有问题,因为有一个解决办法。(您在
cd&
中描述的那张)

我的意见是你正确地使用了
dir
,它只是坏了