@jglick updated, sorry for that

I agree with this "I want the containers to start up as they were built, not with an arbitrary override" from the previous discussion #57 (comment)

Here is very simple example without root which will fail on any of your jenkins instance:
https://github.com/FanchTheSystem/UserPipelineDockerTest

right, but on the other hand some images like the official maven one do run some initial setup in entrypoint for the user, and doing so we will also loose this.

dead end

Is the debate at this point whether it is acceptable/possible at this point to make a breaking change to behavior, or which behavior is "more" right?

We don't have any "correct" solution : both will bring issues with various images. From this point of view keeping the current behaviour without (more) breaking changes is the sole option I can consider.

On solution could be to let -u uid:gid on run, which can be overrided by another -u uid2:gid2 in inside.
Which allows to run the image with one user (root for example) and exec command with the jenkins user

diorcety@c9ea6b0

Any ETA on when this may be addressed?
It's pretty common to run additional setup in an image entrypoint. Forcing to run as the current user breaks that.

I created an new PR with my solution explained above: #160

By my opinion, default behaviour of running docker images from jenkins pipeline must be the same, what you expect and what you get, when running same docker images on your local workspace. At least current situation must be documented and contain examples - because working around what's going on, when you can't reproduce workflow in pipeline take times!