Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set --user on exec, not on main run command #130

Closed
wants to merge 1 commit into from
Closed

Set --user on exec, not on main run command #130

wants to merge 1 commit into from

Conversation

ndeloof
Copy link
Contributor

@ndeloof ndeloof commented Jan 25, 2018

This is a reboot for #57 on a more recent codebase.

Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
@ndeloof ndeloof requested review from abayer and jglick January 25, 2018 13:36
jglick
jglick previously requested changes Jan 25, 2018
withCallback(new Callback(container, toolName)).
start();
@Override
public boolean start() throws Exception {
return false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, what?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems I made something wrong within my IDE without I noticed

@ndeloof
Copy link
Contributor Author

ndeloof commented Jan 25, 2018

@jglick updated, sorry for that

@FanchTheSystem
Copy link

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

@ndeloof
Copy link
Contributor Author

ndeloof commented Feb 21, 2018

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

@adamvoss
Copy link

adamvoss commented May 7, 2018

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?

@ndeloof
Copy link
Contributor Author

ndeloof commented May 7, 2018

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.

@diorcety
Copy link

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
Copy link

diorcety@c9ea6b0

@andrewnicols
Copy link

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.

@diorcety
Copy link

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

@ndeloof ndeloof closed this Feb 27, 2019
@fessmage
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants