title: Using docker command (to host) in docker container with non-root user as Jenkinsfile agent
body: <p>As part of my buildpipeline, I have a container containing build-tools that is used for multiple projects. One of my project contains a build step to build and publish a container, which is done from within the build-tools container. My docker enabled jenkins-slaves are configured to have user <code>jenkins</code> who is in group <code>docker</code>. I used -v to mount the docker binary and scoket. This can be achieved/reproduced by either:</p>
  
  <ul>
  <li>Add the user (jenkins) and group (docker) in the Dockerfile of the build-tools and setting these to the hosts UID and GID</li>
  <li>Start the container with the -u option, providing UID and GUID (as per documentation, user and group does not need to exist within container).</li>
  </ul>
  
  <p>The issue with the first strategy is that the user and group id are different on the multiple build machines. I could fix this by chaning UID and GID of all build machines to the same values, but wasn't docker meant to run in isolation without having many dependencies on the environment/context? This does not feel like the right solution to me.
  The second strategy works perfectly fine on commandline, however, there seems to be no way of passing the UID and GID to the agent command in Jenkinsfile. the <code>args</code> parameter does not support scripts or variables, like <code>$(id -u)</code>.</p>
  
  <p>I expected not to be the first facing this issue, however, I was not able to find a solution to this by myself, search machines and stack overflow. Should I go with 'prepped' build slaves or is there a way to get the second strategy working? </p>
  
  <p>.</p>
  
  <p>-edit-
  I understand the options to run the container as root, and switch after starting (e.g. using entrypoint). However, that would require my Jenkins slave to be connected as root, something that is unacceptable for me. Another found alternative is the chmod777 of all resources, which fully defies the security aspect of not running a Jenkins slave as root user. I would prefer to use the -u option to containers, but I can't find a way to determine the UID and GID on a jenkins slave before starting up the docker agent (<code>docker run</code> command) from within the Jenkinsfile.</p>