Hello Together,

i have the same problem when i try to execute the example from https://jenkins.io/doc/book/pipeline/docker/ on a Windows 10 Jenkins Master.

The Pipline i use is the one from the example: 

Jenkinsfile (Declarative Pipeline)pipeline {
    agent {
        docker { image 'node:7-alpine' }
    }
    stages {
        stage('Test') {
            steps {
                sh 'node --version'
            }
        }
    }
}

And the Error Message i get is following:

C:\Program Files (x86)\Jenkins\workspace\docker-jenkins-test_master>docker inspect -f . python:3.7-alpine 
.
[Pipeline] withDockerContainer
Jenkins does not seem to be running inside a container
$ docker run -d -t -w "C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/" -v "C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/:C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/" -v "C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master@tmp/:C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master@tmp/" -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 ******** python:3.7-alpine cmd.exe
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.io.IOException: Failed to run image 'python:3.7-alpine'. Error: docker: Error response from daemon: the working directory 'C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/' is invalid, it needs to be an absolute path.
See 'docker run --help'.
	at org.jenkinsci.plugins.docker.workflow.client.WindowsDockerClient.run(WindowsDockerClient.java:57)
	at org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:199)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:286)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:179)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
	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:20)
	at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:126)
	at org.jenkinsci.plugins.docker.workflow.Docker.node(Docker.groovy:66)
	at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(Docker.groovy:114)
	at org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.DockerPipelineScript.runImage(DockerPipelineScript.groovy:54)
	at org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.AbstractDockerPipelineScript.configureRegistry(AbstractDockerPipelineScript.groovy:73)
	at org.jenkinsci.plugins.pipeline.modeldefinition.agent.impl.AbstractDockerPipelineScript.run(AbstractDockerPipelineScript.groovy:52)
	at org.jenkinsci.plugins.pipeline.modeldefinition.agent.CheckoutScript.checkoutAndRun(CheckoutScript.groovy:61)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:84)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:113)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:83)
	at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	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: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$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:186)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:370)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:282)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:270)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:66)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	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(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Finished: FAILURE

When i look to the Error Message, it seems there are multiple problems inside:

1. The Docker Container is a Linux Container, so the option "-w" should be a linux path pointing inside the container to a existing folder. (e.g.  /usr/src/app)
2. The volume mount of the container is wrong. Jenkins tries to mount a host Windows path to a container Linux path, using for both paths the windows path style, which is not working. (Is Situation: -v "C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/:C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/") (Should Situation example: -v "C:/Program Files (x86)/Jenkins/workspace/docker-jenkins-test_master/:/docker-jenkins-test_master/")

I've been trying to track this issue. It's a bit of a surprise because there was a big push recently to get Windows supported in version 1.21 of the plugin. The effort culminated in this pull request:

https://github.com/jenkinsci/docker-workflow-plugin/pull/184

I was racking my brain trying to figure out how this was so thoroughly tested, but this path issue exists. The best I can tell, anyone who successfully tested these changes was running Windows containers on a Windows host. In that scenario the paths would be valid for both the host and the container. The error reported here happens when you run Linux containers on a Windows host. An elegant fix for this would be challenging because the environment would need to be checked to see what type of containers Docker is currently configured to run.

I've started to make code changes in my environment to investigate how deep this issue is. I updated the WindowsDockerClient class to change the volume and workDir parameters to have Linux-friendly paths. This clears the issue reported here, but hits a new wall.

I'm testing using withDockerContainer. This function runs cmd.exe to intentially keep the container running indefinitely, but this doesn't exist in Linux containers. Changing it to run 'cat' clears this error and the docker container starts.

Next, it reports that 'cat' isn't running in the container. This is likely due to a different implementation of listProcess in WindowsDockerClient. I'm ignoring this because it seems to just be a warning.

Finally, when my pipeline script attempts to run sh within the container, it freezes indefinitely. I need to manually kill the docker container. I haven't had time to troubleshoot this issue yet.

I'm not sure if i get you correct, but in my understanding the problem is happening only on Windows host (master or slaves), when they try to start a Linux container with a Jenkins Pipeline as you wrote in the first comment.

Are you exectuing the Test on a Windows host, with a Linux Docker Container? I don't get the point what you mean with 'cat', because if the commandline is correct, and Jenkins will start the Linux Container on the host, my expectation would be that it will run with the exactly same behaviour as if i would run it on my commandline on the host directly. 

For sure, now the Test Steps can not more run inside a cmd or bat command, because the jenkins should execute now the command as shell. But if we use the Jenkinsfile like this:

pipeline {
    agent {
        docker { image 'node:7-alpine' }
    }
    stages {
        stage('Test') {
            steps {
                sh 'node --version'
            }
        }
    }
}

then it is already written, that a Linux container is started, and inside the Linux node we call the command sh 'node --version'.

In my understanding the challenge is to transfer the single 'sh' calls from a windows host where we have to use cmd to inside the docker container, and this via a opened cmd, where the docker container is already started.

I'm currently not able to help here in coding, but it would be great to have a solution available which works, but what i can offer currently is the help to perform tests, if this would help here. Maybe also more would be possible, but i'm not familiar with the whole development environment for jenkins currently.

bobby013

I'm referencing a "behind the scenes" aspect about how the docker functionality works. When you enter into a pipeline region where you're running commands inside the docker container, Jenkins will start the docker container and it stays running until you leave that code region. So the order of operations for your sample that runs "node --version" is this:

• Start the docker container
• Run "node --version" inside the container
• Stop the docker container

The method that is used to start the container is a command is run that would never quit. For Linux it runs 'cat' and for Windows it runs 'cmd.exe'. Here is the relevant code from the docker workflow plugin:

String command = launcher.isUnix() ? "cat" : "cmd.exe";
container = dockerClient.run(env, step.image, step.args, ws, volumes, volumesFromContainers, envReduced, dockerClient.whoAmI(), /* expected to hang until killed */ command);

The issue with this is it makes the decision based on the host environment and not the container environment. This decision is baked into the plugin and isn't based on input from the pipeline script. If you're on Windows and trying to run a Linux container, it always chooses to run cmd.exe.

I looked further into the indefinite freezing that I mentioned in a previous comment. My changes to the volume and working directory paths do result in the docker container starting successfully. The freeze is happening during the 'sh' command since the withDockerContainer block. The 'sh' command generates a really complex inline script to track the progress of the command and capture its output. The script's command also gets written to a file and is referenced. There are multiple absolute path references which use Windows's format. These fail on the Linux side and, because no output is written to the proper location, the 'sh' command waits indefinitely for it to finish. (It will eventually time out, but would otherwise wait forever.) If I capture the command in the Jenkins logs and rework all of the paths to be Linux-friendly, the command runs in docker successfully and Jenkins immediately moves to the next pipeline command/step.

I tried to leverage the 'ws' command to force a Linux-friendly path inside the withDockerContainer block, but this causes new problems. Namely it causes the host-side of the 'sh' command to work in the wrong place - causing the same end result. You MIGHT be able to mostly work around this problem by using a Linux-friend path (like "/Jenkins") for the workspace root for the Windows node... but some of the commands may still use backslashes for path separators and cause failures. It's also not a user-friendly solution.

At minimum, it seems like the Decorator class used by withDockerContainer needs to comb through the launcher's commands list ("cmds") and replace all of the Windows paths with Linux-friendly paths. A regular expression might be able to do it, but I haven't tried yet. It's tricky with the amount of text being added to the command list. Maybe someone with more knowledge of Jenkins has a more elegant solution.

I created a fork which contains changes that resolve this issue for my use case. I'd be curious if anyone else could test the changes.

https://github.com/mrsonicblue/docker-workflow-plugin