don’t force user when container starts

[ndeloof]

container may have been designed to start some services used during the build which won't support arbitrary user:group set by jenkins. -user option was introduced into docker-exec in 1.7.0

[ndeloof]

@reviewbybees

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[jenkinsadmin]

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

[jglick]

Could just delete this parameter, assuming there is no other use.

[jglick]

Sounds right; did you check the functional tests (not currently run by CI), and the demo image? Also IIRC @svanoort and @rtyler had some experiences relating to UID and Image.inside so they may wish to comment.

[svanoort]

I think if I read this correctly, it won't pose an issue for docker.inside because the Decorator is still fetching the current UID (needed for the workspace mounting). However there are options to run without a supplied user id. There's some complexity in the groovy that invokes these though, which I don't 100% follow.

@ndeloof is this accurate?

[jglick]

Is this addressing JENKINS-34289?

[ndeloof]

assuming JENKINS-34289 is about entrypoint running some commands the forced user can't execute, this indeed would solve it.

[docwhat]

Yeah, I think that was only part of the issue... because I worked around it by creating the correct user/group in the container before running it.

[antoniobeyah]

I am running into this same issue- I was able to merge this pr locally and get the plugin working in my jenkins. Are we able to get this PR merged?

If you want, I can resolve the conflicts and get this passing. The conflicts are minimal and pretty easy to resolve.

cc: @ndeloof @jglick

[jglick]

Are we able to get this PR merged?

If you can

• resolve the merge conflicts
• verify whether or not this is fixing JENKINS-34289
• provide some kind of test case demonstrating that the PR fixes something (an automated test in src/test/java/ would be ideal, but if that is technically challenging, descriptive steps for running such a test manually would suffice)

[antoniobeyah]

sounds good, i'll likely start working on this tomorrow.

[kevinroisin]

+1 for this. If I may, what's the status of it?

[j1n6]

This would be really handy. +1

[jglick]

Superseded by #60 I suppose.

[jglick]

#57 I meant of course.