jenkinsci / jenkinsci/docker-workflow-plugin
[JENKINS-61498] Docker inside Docker not detected correctly with Windows Containers
- Dominant language
- Java
- Stars
- 527
- Forks
- 422
- Avg merge
- 10m
- Merged PRs (30d)
- 1
Description
The logic in https://github.com/jenkinsci/docker-workflow-plugin/blob/5191865cd0126b3d25ef11fd03bf932c4178ea91/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java#L337 currently does not handle windows containers properly.
The result of this is that the magic volumes from container logic https://github.com/jenkinsci/docker-workflow-plugin/blob/1089131014350e11adfa364d34e7717954350261/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L181 is not being invoked in cases where it's needed.
In my situation I've worked around the issue by exposing making workspace root a bind mount to the same path on the host, but it would be nice if this "just works".
At least when using the Docker Agent plugin (https://plugins.jenkins.io/docker-plugin/) it looks like the container ID is available inside the job as an environment variable DOCKER_CONTAINER_ID. I imagine this is a special case from the docker-plugin setting this up though. I'm not sure what the correct general way to determine the container id with Windows Containers, but leveraging DOCKER_CONTAINER_ID where available would be better than nothing.
---
Originally reported by 
nvx, imported from: Docker inside Docker not detected correctly with Windows Containers
Raw content of original issue
The logic in https://github.com/jenkinsci/docker-workflow-plugin/blob/5191865cd0126b3d25ef11fd03bf932c4178ea91/src/main/java/org/jenkinsci/plugins/docker/workflow/client/DockerClient.java#L337 currently does not handle windows containers properly.
The result of this is that the magic volumes from container logic https://github.com/jenkinsci/docker-workflow-plugin/blob/1089131014350e11adfa364d34e7717954350261/src/main/java/org/jenkinsci/plugins/docker/workflow/WithContainerStep.java#L181 is not being invoked in cases where it's needed.
In my situation I've worked around the issue by exposing making workspace root a bind mount to the same path on the host, but it would be nice if this "just works".
At least when using the Docker Agent plugin (https://plugins.jenkins.io/docker-plugin/) it looks like the container ID is available inside the job as an environment variable DOCKER_CONTAINER_ID. I imagine this is a special case from the docker-plugin setting this up though. I'm not sure what the correct general way to determine the container id with Windows Containers, but leveraging DOCKER_CONTAINER_ID where available would be better than nothing.
Contributor guide
Assessment
This issue has not been assessed yet.