We use Docker slaves, and inside the image we create a user jenkins:
RUN useradd jenkins -m -d /build
We also use a volume for cached dependencies downloaded by Groovy Grapes. Without this volume, each new Docker slave would download all dependencies, making the build much slower.
This leads to a problem: all downloaded and cached dependencies belong to some irrelevant user, that by chance has the same uid as the user jenkins in the container:
With console docker client, we could fix this problem by running the container as user jenkins:
docker run --user jenkins my_image
However, there is no such option in the Docker Plugin configuration.
A workaround is to create user jenkins on the host machine running Docker containers with the same uid and gid as within the container. With many images and many host machines, this workaround seems poor.
Well, it looks like the underlying docker-java library probably supports a user argument, so it shouldn't be too tricky to implement.
If you create a PR, I'd be happy to review it.
We use Docker slaves, and inside the image we create a user
jenkins
:We also use a volume for cached dependencies downloaded by Groovy Grapes. Without this volume, each new Docker slave would download all dependencies, making the build much slower. This leads to a problem: all downloaded and cached dependencies belong to some irrelevant user, that by chance has the same uid as the user
jenkins
in the container:With console docker client, we could fix this problem by running the container as user
jenkins
:However, there is no such option in the Docker Plugin configuration. A workaround is to create user
jenkins
on the host machine running Docker containers with the same uid and gid as within the container. With many images and many host machines, this workaround seems poor.Jenkins 2.164.2 Docker Plugin 1.1.6 Docker Commons Plugin 1.14