[JIRA] (JENKINS-60119) Declarative pipeline with Docker image not running steps inside container on Windows

[medianick@gmail.com (JIRA)]

Nick Jones created an issue

Jenkins / JENKINS-60119 Declarative pipeline with Docker image not running steps inside container on Windows Issue Type: Bug Assignee: Unassigned Components: docker-workflow-plugin Created: 2019-11-10 17:14 Environment: Windows Server 2019 (1809) agent node running Docker 19.03.4, Docker Pipeline 1.21 Priority: Minor Reporter: Nick Jones I'm running a very simple test with a Nano Server container, now that the Docker Pipeline plugin has Windows support, but the steps in my stage appear to be running in the agent node instead. The pipeline looks like this: pipeline { agent { docker { image 'mcr.microsoft.com/windows/nanoserver:1809' } } stages { stage('Test') { steps { bat 'echo I am a temporary file >> temp.txt' bat 'type temp.txt' } } } } However, the temp.txt file I append to is getting longer and longer (as it's appended to with each build, and nothing deletes it), and indeed I can see it sitting in the filesystem on my agent node that runs Docker. For example, the console log shows this for my 4th build: 00:00:04.251 C:\Jenkins\workspace\Sandbox\DockerTest>echo I am a temporary file 1>>temp.txt 00:00:04.259 [Pipeline] bat 00:00:04.563 00:00:04.563 C:\Jenkins\workspace\Sandbox\DockerTest>type temp.txt 00:00:04.563 I am a temporary file 00:00:04.563 I am a temporary file 00:00:04.563 I am a temporary file 00:00:04.563 I am a temporary file Am I missing something fundamental about how this is supposed to work? I had expected this syntax would result in the echo and type commands being run in a container that was then discarded, resulting in an entirely new temp.txt file each time, and nothing left over. Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[medianick@gmail.com (JIRA)]

Nick Jones commented on JENKINS-60119

Re: Declarative pipeline with Docker image not running steps inside container on Windows Ah, indeed I may have misunderstood how this works: the build is running  $ docker run -d -t -w C:/Jenkins/workspace/Sandbox/DockerTest/ -v C:/Jenkins/workspace/Sandbox/DockerTest/:C:/Jenkins/workspace/Sandbox/DockerTest/ -v C:/Jenkins/workspace/Sandbox/DockerTest@tmp/:C:/Jenkins/workspace/Sandbox/DockerTest@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 ******** -e ******** -e ******** mcr.microsoft.com/windows/nanoserver:1809 cmd.exe This means the Docker is being instructed to mount the agent's workspace as a shared volume, which means that by design it's picking up whatever happens to be in that workspace (e.g., artifacts left over from previous builds). However, I cannot seem to clean the workspace using cleanWs() to remove those artifacts; if I try I get this: ERROR: Cannot delete workspace: Unable to delete 'C:\Jenkins\workspace\Sandbox\DockerTest'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts. 0 It seems my only automated recourse would be to leverage a Git checkout behavior such as "wipe out repository & force clone" to guarantee a fresh workspace. That's a separate issue, I suppose.

Add Comment

[medianick@gmail.com (JIRA)]

Nick Jones updated an issue

Jenkins / JENKINS-60119

Declarative pipeline with Docker image not running steps inside container on Windows

Change By: Nick Jones I'm running a very simple test with a Nano Server container, now that the Docker Pipeline plugin has [Windows support|https://github.com/jenkinsci/docker-workflow-plugin/releases/tag/docker-workflow-1.21], but the steps in my stage appear to be running in on the agent node instead. The pipeline looks like this: {code:java}

pipeline {   agent {     docker {       image 'mcr.microsoft.com/windows/nanoserver:1809'     }   }   stages {     stage('Test') {       steps {         bat 'echo I am a temporary file >> temp.txt'         bat 'type temp.txt'       }     }   } }

{code}

However, the {{temp.txt}} file I append to is getting longer and longer (as it's appended to with each build, and nothing deletes it), and indeed I can see it sitting in the filesystem on my agent node that runs Docker. For example, the console log shows this for my 4th build:

{noformat} 00:00:04.251  C:\Jenkins\workspace\Sandbox\DockerTest>echo I am a temporary file  1>>temp.txt

00:00:04.259  [Pipeline] bat 00:00:04.563

00:00:04.563  C:\Jenkins\workspace\Sandbox\DockerTest>type temp.txt

00:00:04.563  I am a temporary file 00:00:04.563  I am a temporary file 00:00:04.563  I am a temporary file 00:00:04.563  I am a temporary file

{noformat}

Am I missing something fundamental about how this is supposed to work? I had expected this syntax would result in the {{echo}} and {{type}} commands being run in a container that was then discarded, resulting in an entirely new {{temp.txt}} file each time, and nothing left over.

Add Comment

[medianick@gmail.com (JIRA)]

Nick Jones edited a comment on JENKINS-60119

Re: Declarative pipeline with Docker image not running steps inside container on Windows

Ah, indeed I may have misunderstood how this works: the build is running

{noformat}

$ docker run -d -t -w C:/Jenkins/workspace/Sandbox/DockerTest/ -v C:/Jenkins/workspace/Sandbox/DockerTest/:C:/Jenkins/workspace/Sandbox/DockerTest/ -v C:/Jenkins/workspace/Sandbox/DockerTest@tmp/:C:/Jenkins/workspace/Sandbox/DockerTest@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 ******** -e ******** -e ******** mcr.microsoft.com/windows/nanoserver:1809 cmd.exe

{noformat} This means the Docker is being instructed to mount the agent's workspace as a shared volume, which means that _by design_ it's picking up whatever happens to be in that workspace (e.g., artifacts left over from previous builds). However, I cannot seem to clean the workspace using {{cleanWs()}} to remove those artifacts; if I try I get this: {noformat}

ERROR: Cannot delete workspace: Unable to delete 'C:\Jenkins\workspace\Sandbox\DockerTest'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts. 0

{noformat} ( It does actually delete the workspace, it seems , but it still fails the build.) As far as I can tell, my only automated recourse would be to leverage a Git checkout behavior such as "wipe out repository & force clone" to guarantee a fresh workspace. That I ' s ll consider that a separate issue , I suppose .

Add Comment

[medianick@gmail.com (JIRA)]

Nick Jones resolved as Not A Defect

As noted in my previous comment, this seems to be the intended behavior, where the workspace from the agent node gets shared with the running container. I have a separate challenge in wiping the workspace effectively in this scenario, but it's not the bug I originally reported, so I'm closing this one.

Jenkins / JENKINS-60119

Declarative pipeline with Docker image not running steps inside container on Windows

Change By: Nick Jones Status: Open Resolved Resolution: Not A Defect

Add Comment