> On Jan 11, 2019, at 11:23 PM, Dominik Psenner <dpsen...@gmail.com> wrote:
>
> I can enlist another pain point I faced while implementing the pipeline for
> log4net. I had to find a way of detecting the uid/guid of the jenkins user
> to make it work with dotnet core commandline inside docker. That really got
> my head aching and as far as I can remember stemmed from the fact that the
> dotnet commandline was unable to the detect the home directory and
> attempted to write files into places of the filesystem that it was not
> supposed to.
I’m guessing you are using maven via the docker agent? In my
experiences, this is a combination of docker implementation details, missing
features in Jenkins, and misleading maven documentation (hint: system property
user.home does not always equal $HOME!). There is a not-very-well documented
workaround probably because it demonstrates a security weakness in the Jenkins
agent+Docker. Just mount /etc/passwd and friends in your container:
pipeline {
agent {
docker {
image ‘foo’
label ‘bar'
args ‘-v /etc/passwd:/etc/passwd:ro -v
/etc/group:/etc/group:ro -v ${HOME}:${HOME}’
}
}
…
}
Note that for Docker-in-Docker setups, this sometimes completely falls
apart (e.g, jnlp and OS X agents) due to the docker daemon running in a
different namespace of where the jenkins users is. (OS X’s docker
implementation just flat out lies about the universe!) There’s also the issue
of conflicting user/group definitions but it is what it is. Luckily, this
usually works well enough to workaround executables that don’t honor $HOME
variables and instead look at passwd information.
For Apache Yetus, we do a few things to circumvent this problem,
including making sure ${HOME} is defined and doing run specific docker images (
https://github.com/apache/yetus/blob/master/precommit/src/main/shell/test-patch-docker/Dockerfile.patchspecific
) based upon a provided docker file or docker tag.
I wish Jenkins did something similar. If it provided a hook to a run
specific Dockerfile that does the necessary magic before launching so that the
Jenkins user could be defined we’d all be better off. (cgroup+user remapping
might also work but I doubt it.)
