Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-49416

Agent Dockerfile Overrides Entrypoint and User

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: docker-workflow-plugin
    • Labels:
    • Environment:
      Jenkins 2.89.3
      docker-workflow 1.15 (Also tried 1.14)
      Docker version 17.12.0-ce, build c97c6d6
    • Similar Issues:

      Description

       

      I am running a project build inside the docker container build from the repo's Dockerfile. This dockerfile has an entrypoint that is respectful of commands being passed in as has been discussed on similar issues recently. The entrypoint starts a few services that are necessary for the build steps. Jenkinsfile:

      #.Jenkinsfile
      pipeline {
      agent { dockerfile true }
      
        stages {
          stage('Build') {
            steps {
              sh 'echo whoami'
              sh 'ps -ef'
            }
          }
        }
      }

       

      The problem is that the steps get run in the docker container, but the user and entrypoint are both overridden with no option that I can find to change that behavior. I think this breaks what a new user like myself would expect to happen and there doesn't seem to be any documentation to warn of this or to work around this. 

      Looking at the console output, it appears the plugin infers to add withDockerContainer somewhere before the steps execute. This step may be hard to replicate since the plugin knows how to build the dockerfile and use that resulting image for the rest of the steps.

      There should be some way to avoid the overriding of the user and entrypoint when running from a dockerfile or at least a documented workaround.

        Attachments

          Issue Links

            Activity

            Hide
            satchm0h Ted Bedwell added a comment - - edited

            I would like to add my support for this request. In my use case, I do not leverage entrypoints, but my Dockerfile sets up a build user account, lays out a bunch of dependencies and directory structures used to genreate the artifacts, and drops priveleges with the Dockerfile USER command which gets smashed by the Jenkins docker run commandline hardcoded -u.

            I will move ahead refactoring my Dockerfiles to make this work. That said, I agree wholeheartedly with Joe Adams that the inability to override the user:group (and entrypoint in his case) is a barrier for newcomers. Particularly if they already have their docker-fu working. I have no issue w/ the default behavior remaining the same, but I dont understand the reticense (from previous issues) to provide the capability to override the default behavior.

            Another potential alternative would be an option to add the Jenkins UID  to a NOPASSWD sudo entry (if /etc/sudoers exists). This would allow us to change our uid at runtime.

            Edit : JENKINS-47026 : Provides an interesting workaround for the user issue for others that stumble across this.

            Show
            satchm0h Ted Bedwell added a comment - - edited I would like to add my support for this request. In my use case, I do not leverage entrypoints, but my Dockerfile sets up a build user account, lays out a bunch of dependencies and directory structures used to genreate the artifacts, and drops priveleges with the Dockerfile USER command which gets smashed by the Jenkins docker run commandline hardcoded -u. I will move ahead refactoring my Dockerfiles to make this work. That said, I agree wholeheartedly with Joe Adams that the inability to override the user:group (and entrypoint in his case) is a barrier for newcomers. Particularly if they already have their docker-fu working. I have no issue w/ the default behavior remaining the same, but I dont understand the reticense (from previous issues) to provide the capability to override the default behavior. Another potential alternative would be an option to add the Jenkins UID  to a NOPASSWD sudo entry (if /etc/sudoers exists). This would allow us to change our uid at runtime. Edit : JENKINS-47026 : Provides an interesting workaround for the user issue for others that stumble across this.

              People

              • Assignee:
                Unassigned
                Reporter:
                sysadmind Joe Adams
              • Votes:
                3 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: