I have a pretty standard Dockerfile:
FROM python:3.6.5
WORKDIR /src
COPY . /src
... install and configure things ...
and a pretty standard Jenkinsfile
pipeline {
agent none
stages {
stage('Test') {
agent { dockerfile true }
steps {
dir('/src') {
sh 'pwd' // any command
}
}
}
}
}
However when this is run in Jenkins (I should mention I'm currently testing using a local Jenkins instance in a docker container) the Dockerfile builds successfully but when Jenkins attempts to run the step I get the following output:
[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
which is not expected, and when the step is "finished" there is the following failure message:
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
The problem appears to be with this line: docker run -t -d -u 1000:1000 there is no user with UID 1000 on the container built by the Dockerfile, commands are run by root and therefore with the directory change to /src the "user" that jenkins specifies has no access to the files.
How do you prevent Jenkins from trying to use -u 1000:1000 by default? or what steps should I take to resolve this issue. I could in theory add a chmod 777 into the dockerfile but this seems like an ugly workaround
Update:
I added RUN chmod -R 777 /src to my Dockerfile but the issue remains. If I run the container manually from inside the docker Jenkins container:
docker run -it -u 1000:1000 -w "/var/jenkins_home/workspace/My Project" --volumes-from aaee62f2a28e29b94c13fcdc08c1a82ef7baed48beabe54579db07b2fbd26b23 12724611f0bf2363c9eee7288654e43eca2aabaf /bin/bash
and cd /src I have access to the files and can do e.g. touch newfile without issues. The java.nio.file.AccessDeniedException: /src still appears in the logs though
It seems that you can override/pass docker arguments according to this, so you might try this in order to override the default using uid/gid
args: A string. Runtime arguments to pass to docker run.
This option is valid for docker and dockerfile.
agent {
dockerfile {
args '-u 0:0' // or try to make it -u root
}
}
Related
We have a Jenkins file that looks as follow
pipeline {
agent {
node {
label 'slave-test'
}
}
stages {
stage ('test docker run') {
agent {
docker {
image 'node:14.4.0-slim'
args '-u root -v /var/run/docker.sock:/var/run/docker.sock'
reuseNode true
}
}
steps {
sh 'PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true npm ci'
sh 'npm run test:ci'
sh 'npm run patternlab:build'
}
}
}
The node labelled as slave-test is a docker-swarm client running as a docker image based on debian-buster. Inside this slave we want to start the image node:14.4.0-slim to run some tests and package some frontend-stuff.
We use reuseNode = true to use the same workspace as agent in the beginning of the pipeline. But Jenkins tells us :
[Pipeline] {
[Pipeline] stage
[Pipeline] { (test docker run)
[Pipeline] getContext
[Pipeline] isUnix
[Pipeline] sh
13:24:07 + docker inspect -f . node:14.4.0-slim
13:24:07 .
[Pipeline] withDockerContainer
13:24:07 hofladen-slave01-20d7912d seems to be running inside container 23d34522985b2e7ec99327337cd2b20bee22018562886c9930a4ba777cda11ca
13:24:07 but /home/****/workspace/ttern-library_feature_BWEBHM-262#2 could not be found among [/var/run/docker.sock]
13:24:07 but /home/****/workspace/ttern-library_feature_BWEBHM-262#2#tmp could not be found among [/var/run/docker.sock]
13:24:07 $ docker run -t -d -u 10000:10000 -u root -v /var/run/docker.sock:/var/run/docker.sock -w /home/****/workspace/ttern-library_feature_BWEBHM-262#2 -v /home/****/workspace/ttern-library_feature_BWEBHM-262#2:/home/****/workspace/ttern-library_feature_BWEBHM-262#2:rw,z -v /home/****/workspace/ttern-library_feature_BWEBHM-262#2#tmp:/home/****/workspace/ttern-library_feature_BWEBHM-262#2#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 ******** -e ******** -e ******** -e ******** -e ******** node:14.4.0-slim cat
13:24:08 $ docker top 0759f74d1c2676d68a32edab9775b2ca3c518fa2e4e673af856a87e9da514683 -eo pid,comm
[Pipeline] {
[Pipeline] sh
13:29:15 process apparently never started in /home/****/workspace/ttern-library_feature_BWEBHM-262#2#tmp/durable-504ce105
13:29:15 (running Jenkins temporarily with -Dorg.****ci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer)
[Pipeline] }
13:29:15 $ docker stop --time=1 0759f74d1c2676d68a32edab9775b2ca3c518fa2e4e673af856a87e9da514683
13:29:17 $ docker rm -f 0759f74d1c2676d68a32edab9775b2ca3c518fa2e4e673af856a87e9da514683
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Cancel running builds if exist)
Stage "Cancel running builds if exist" skipped due to earlier failure(s)
We need to run these commands all in the same Jenkins Workspace in order to perform the later steps.
Does anybody have an Idea how to achive this. We know that the pipeline runs fine if the pipeline is not running on an agent that is on a standalone machine.
Fixed by starting jenkins slave as container with a volume to share data and allow access to /var/run/docker.sock
#!/bin/bash
volume_name=myfinevolume-slave01-workspace
docker volume create ${volume_name}
docker run -d --name jenkins-agent-for-myfineproject \
-v /var/run/docker.sock:/var/run/docker.sock:rw \
--mount source=${volume_name},target=/home/jenkins/workspace \
--memory=8G \
--memory-swap=16G \
--restart unless-stopped \
myfineregsitry.domain.lala/acme/jenkins-swarm-client:3.17.0_buster
I'm using Alpine docker image as a Jenkins pipeline agent but I keep getting permission denied error while running apk update or apk add package. I seeing similar error for Ubuntu images also while running apt update or apt install
Here's my Jenkinsfile:
pipeline {
agent none
stages {
stage('Initialization') {
agent any
steps {
checkout scm
}
}
stage('Git Clone') {
agent { docker { image 'alpine:3.12.0' } }
steps {
sh '''
apk update;
apk add --no-cache git;
apk add --no-cache openssh;
git -v;
'''
}
}
}
}
and here's the Jenkins output:
+ docker inspect -f . alpine:3.12.0
WARNING: Error loading config file: /root/.docker/config.json: stat /root/.docker/config.json: permission denied
.
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
$ docker run -t -d -u 1001:0 -w "/opt/bitnami/jenkins/jenkins_home/workspace/Deploy Glosfy Frontend" -v "/opt/bitnami/jenkins/jenkins_home/workspace/Deploy Glosfy Frontend:/opt/bitnami/jenkins/jenkins_home/workspace/Deploy Glosfy Frontend:rw,z" -v "/opt/bitnami/jenkins/jenkins_home/workspace/Deploy Glosfy Frontend#tmp:/opt/bitnami/jenkins/jenkins_home/workspace/Deploy Glosfy Frontend#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 ******** alpine:3.12.0 cat
$ docker top 166c9ace17a4eb6aef0af0bbc04902ee4a358212be7f029550fb39a921e305aa -eo pid,comm
[Pipeline] {
[Pipeline] sh
+ apk update
ERROR: Unable to lock database: Permission denied
ERROR: Failed to open apk database: Permission denied
[Pipeline] }
$ docker stop --time=1 166c9ace17a4eb6aef0af0bbc04902ee4a358212be7f029550fb39a921e305aa
$ docker rm -f 166c9ace17a4eb6aef0af0bbc04902ee4a358212be7f029550fb39a921e305aa
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] End of Pipeline
ERROR: script returned exit code 99
Finished: FAILURE
Can someone help me figure out the issue?
Please modify the docker tag from Jenkins pipeline like this:
docker {
image 'alpine:3.12.0'
args '-u root:root'
}
I believe the problem is that Jenkins is running the container with a non-root user, hence the Permission denied error.
Try changing your pipeline like so:
agent {
docker {
image 'alpine:3.12.0'
args '-u root'
}
}
See this answer.
Following on from the issue I had in this question: Why when using Jenkins dockerfile agent does it run container with invalid user?
I successfully managed to run the container as root user, however the actual java stack trace failure I received remained the same- implying it is not a permissions error with the user in the container.
The actual issue appears to be with the dir() {} step within my stage. To re-iterate, when I have the following:
steps {
dir('/src') {
sh 'pwd' // any command
}
}
the container exits without running the command:
[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
and the failure stack trace at the end of the build is:
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
However if I use the following:
steps {
sh 'cd /src && pwd'
}
The command runs as expected. Is this a bug within Jenkins or am I misunderstanding what the dir() directive is used for?
Generally speaking, The dir() directive's purpose is to change your current working directory to another directory on the jenkins agent where the build itself is running.
In your case specifically there is a limitation from the docker plugin side as explained in the following issue's comment:
dir with an absolute path is not supported inside a Docker container. 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.
So your current workaround sh 'cd /src' - if we considered it a workaround - is the recommended way to do it.
I agree that this is a bug. And reported the issue here: https://issues.jenkins-ci.org/browse/JENKINS-46055
The core maintainers seemed to feel that there isn't actually a problem because there is a workaround. (the one you described of cd <dir> && <cmd>)
My opinion is that you're using dir correctly, it's just broken.
I've created image that use for jenkins agent slave
Here it is: https://hub.docker.com/r/kondaurov/jenkins_agent/~/dockerfile/
Than i run it:
docker run -d -p 2222:22 --name=jenkins_agent -v /var/run/docker.sock:/var/run/docker.sock -v kondaurov/jenkins_agent
Then i create new node in jenkins and it connects successfully via ssh
I try to run this pipeline:
pipeline {
agent {
docker {
label 'agent01'
image 'hello-world'
}
}
stages {
stage('Compile') {
steps {
sh 'whoami'
sh 'echo $PATH'
}
}
}
}
agent01 - is a container with my slave image
But it fails..
Started by user Alexander Mac Replayed #18
git rev-parse --is-inside-work-tree # timeout=10 Setting origin to https://github.com/kondaurov-scala/snippets.git
git config remote.origin.url https://github.com/kondaurov-scala/snippets.git # timeout=10 Fetching
origin... Fetching upstream changes from origin
git --version # timeout=10 using GIT_SSH to set credentials
git fetch --tags --progress origin +refs/heads/:refs/remotes/origin/ Seen branch in repository origin/1.1.0 Seen branch in repository origin/master Seen 2 remote
branches Obtained Jenkinsfile from
5d917470103056b70398465c0d8a56b127f9e036 [Pipeline] node Running on
agent01 in
/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q
[Pipeline] { [Pipeline] stage [Pipeline] { (Declarative: Checkout SCM)
[Pipeline] checkout
git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository
git config remote.origin.url https://github.com/kondaurov-scala/snippets.git # timeout=10 Fetching
without tags Fetching upstream changes from
https://github.com/kondaurov-scala/snippets.git
git --version # timeout=10 using GIT_SSH to set credentials
git fetch --no-tags --progress https://github.com/kondaurov-scala/snippets.git
+refs/heads/:refs/remotes/origin/ Checking out Revision 5d917470103056b70398465c0d8a56b127f9e036 (1.1.0) Commit message: "ref"
git config core.sparsecheckout # timeout=10
git checkout -f 5d917470103056b70398465c0d8a56b127f9e036
git rev-list 5d917470103056b70398465c0d8a56b127f9e036 # timeout=10 [Pipeline] } [Pipeline] // stage [Pipeline] withEnv [Pipeline] {
[Pipeline] stage [Pipeline] { (Declarative: Agent Setup) [Pipeline] sh
[hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q]
Running shell script
+ docker pull hello-world Using default tag: latest latest: Pulling from library/hello-world 5b0f327be733: Pulling fs layer 5b0f327be733:
Verifying Checksum 5b0f327be733: Download complete 5b0f327be733: Pull
complete Digest:
sha256:b2ba691d8aac9e5ac3644c0788e3d3823f9e97f757f01d2ddc6eb5458df9d801
Status: Downloaded newer image for hello-world:latest [Pipeline] }
[Pipeline] // stage [Pipeline] sh
[hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q]
Running shell script
+ docker inspect -f . hello-world . [Pipeline] withDockerContainer agent01 seems to be running inside container
c6ad60fd4215a35009accd0be49fbe1ebb583b18b12bf87ba80141b63ae9221a but
/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q
could not be found among [/var/run/docker.sock] but
/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q#tmp
could not be found among [/var/run/docker.sock] $ docker run -t -d -u
1000:1000 -w
/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q
-v /home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q:/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q:rw,z -v /home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q#tmp:/home/jenkins/workspace/hello_world_1.1.0-NAIZYV5H2QFOICXMDYZJM3A6XMQ4YL2QYG5ZWJDDWOEWF27RHL7Q#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 ******** --entrypoint cat hello-world [Pipeline] // withDockerContainer [Pipeline] } [Pipeline] // withEnv
[Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline
java.io.IOException: Failed to run image 'hello-world'. Error: docker:
Error response from daemon: oci runtime error: container_linux.go:262:
starting container process caused "exec: \"cat\": executable file not
found in $PATH". at
org.jenkinsci.plugins.docker.workflow.client.DockerClient.run(DockerClient.java:138)
at
org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:179)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:224)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150)
at
org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
at
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at
com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19)
at
org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/Users/Shared/Jenkins/Home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:128)
at
org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/Users/Shared/Jenkins/Home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63) at
org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/Users/Shared/Jenkins/Home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:116)
at
org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.DockerPipelineScript.runImage(jar:file:/Users/Shared/Jenkins/Home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy:57)
at
org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.AbstractDockerPipelineScript.configureRegistry(jar:file:/Users/Shared/Jenkins/Home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/AbstractDockerPipelineScript.groovy:68)
at
org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.AbstractDockerPipelineScript.run(jar:file:/Users/Shared/Jenkins/Home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/AbstractDockerPipelineScript.groovy:54)
at
org.jenkinsci.plugins.pipeline.modeldefinition.agent.CheckoutScript.checkoutAndRun(jar:file:/Users/Shared/Jenkins/Home/plugins/pipeline-model-extensions/WEB-INF/lib/pipeline-model-extensions.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/agent/CheckoutScript.groovy:60)
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.GeneratedMethodAccessor603.invoke(Unknown Source) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483) at
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at
com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
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:122)
at
org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
at
org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)
at
org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35)
at
org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32)
at
org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
at
org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32)
at
org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242)
at
org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230)
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:112)
at
jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
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:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745) Finished: FAILURE
In my case, that message:
sl01978v-98210312 seems to be running inside container d93e0112b277e94c11bac40af30ddd13ef39cb312caca839497e012cd71bdf86
but /opt/jenkins/workspace/gopvolging_jenkins-somebranch could not be found among [jenkins_slave]
but /opt/jenkins/workspace/gopvolging_jenkins-somebranch#tmp could not be found among [jenkins_slave]
... was caused by the fact that the jenkins slave (which is a docker container) didn't have any volume or mount for the workspace, so the --volume-from option that Jenkins automatically passes in a DiD scenario couldn't be added. It instead tried to pass the workspace in -v, but that wasn't shared with the Jenkins slave container, so it kept waiting endlessly on the first sh command. Adding a volume for the Jenkins workspace solved it:
sl01978v-fbd455e0 seems to be running inside container 0f0090afbcece077f492be581170bf9ffb778c75e23144ccf303e9f47e9cfdd5
$ docker run -t -d -u 1000:1000 -w /opt/jenkins/workspace/gopvolging_jenkins-somebranch --volumes-from 0f0090afbcece077f492be581170bf9ffb778c75e23144ccf303e9f47e9cfdd5 ...
(the magic being --volume-from)
Try to link the remote root directory of the slave container to your host /tmp folder.
It appears to be /home/jenkins/ in your case
docker run -d -p 2222:22 --name=jenkins_agent -v /var/run/docker.sock:/var/run/docker.sock -v /tmp:/home/jenkins
I recently upgraded my jenkins/Docker installation and since, I randomly experience timeout when i run a docker in my jenkins pipeline scripts, in which I start a docker like:
docker.image("${dockerImage}").inside(' -v /opt/software/:/software/:Z'){
.....
}
This occurs randomly and my job crash with the following error message ( see extended log at the bottom of this thread):
ERROR: Timeout after 10 seconds
UPDATE:
My pipeline script:
stage('Build'){
node("master"){
withEnv(['GIT_SSL_NO_VERIFY=true']){
checkout([$class: 'GitSCM', branches: [[name: "$myGitSHA"]], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId:"${myGitCredentialsId}" , url:"${myGitUrl}" ]]])
}
docker.image("${dockerImage}").inside(' -v /opt/software/:/software/:Z'){
// Cleaning any the previous build
sh "make all"
} // docker
} // node
} // stage
I wonder whether there is an option to increase the default timeout value set currently to 10s.
thanks
$ docker run -t -d -u 995:993 -v /opt/software/:/software/:Z -w /var/lib/jenkins/jobs/RegressionTests/jobs/rg_centos5-x86_64-gcc-4.1.2/workspace
-v /var/lib/jenkins/jobs/RegressionTests/jobs/rg_centos5-x86_64-gcc-4.1.2/workspace:/var/lib/jenkins/jobs/RegressionTests/jobs/rg_centos5-x86_64-gcc-4.1.2/workspace:rw
-v /var/lib/jenkins/jobs/RegressionTests/jobs/rg_centos5-x86_64-gcc-4.1.2/workspace#tmp:/var/lib/jenkins/jobs/RegressionTests/jobs/rg_centos5-x86_64-gcc-4.1.2/workspace#tmp:rw
-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 ******** --entrypoint cat centos5_labs_ompi14
ERROR: Timeout after 10 seconds
java.io.IOException: Failed to run image 'centos5_labs_ompi14'. Error:
at org.jenkinsci.plugins.docker.workflow.client.DockerClient.run(DockerClient.java:127)
at org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:178)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:184)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:18)
at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:128)
at org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63)
at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:116)
at Script1.extMain(Script1.groovy:305)
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.GeneratedMethodAccessor349.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.ClosureBlock.eval(ClosureBlock.java:46)
at com.cloudbees.groovy.cps.Next.step(Next.java:74)
at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:165)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
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:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
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:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
the issue is due to the hardcoded 10s timeout value, as one can read it from this link;
docker workflow plugin
https://github.com/jenkinsci/docker-workflow-plugin/blob/master/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java#L268
In some cases this is far too short. A solution would be to have this timeout value as a parameter which is set by the user.
I also run into the same problem since yesterday. my docker pipeline version is 1.10.
The issue happens when it try to initiate the docker container from the fol
def abcd_image = docker.image('172.16.181.203:5000/abcd:1.0.0.7')
abcd_image.inside("--privileged -u root -v ${actual_workspace}:${chroot}/code") {
I tried ssh into the docker host and restart docker service. After that, it works but the issue comes back after couple hours.
You can manually set the timeout limit using the "timeout" option.
Set a timeout period for the Pipeline run, after which Jenkins should abort the Pipeline. For example:
options { timeout(time: 1, unit: 'HOURS') }
https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-timeout-code-enforce-time-limit