• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • docker-workflow-plugin
    • None
    • problem occurs on version 1.15 and above of the plugin

      I write a dead simple Dockerfile

      FROM openjdk:8-jdk-alpine
      ENTRYPOINT "java"
      

      I write a dead simple declarative pipeline

      pipeline {
          agent { dockerfile true }
          stages {
              stage('Dead Simple') {
                  steps {
                      checkout scm
                  }
              }
          }
       }

      I get an error.

      I get the same error with 

      pipeline {
          agent { docker { image 'openjdk:8-jdk-alpine' } }
          stages {
              stage('Dead Simple') {
                  steps {
                      checkout scm
                  }
              }
          }
      }

      The error is

      ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
      Alternatively you can force image entrypoint to be disabled by adding option `--entrypoint=''`.
      

      I cannot pass --entrypoint to the run command, it's jenkins that calls it

      a bit more logs :

      [Pipeline] withDockerContainer
      Jenkins does not seem to be running inside a container
      $ docker run -t -d -u 107:111 -w /var/lib/jenkins/workspace/oh-pr0009-api_master-IFYDNFODANQT2HMWSAOO6P6UKZZUCWSO2LNM2M6G7DUPGPLNH7HA -v /var/lib/jenkins/workspace/oh-pr0009-api_master-IFYDNFODANQT2HMWSAOO6P6UKZZUCWSO2LNM2M6G7DUPGPLNH7HA:/var/lib/jenkins/workspace/oh-pr0009-api_master-IFYDNFODANQT2HMWSAOO6P6UKZZUCWSO2LNM2M6G7DUPGPLNH7HA:rw,z -v /var/lib/jenkins/workspace/oh-pr0009-api_master-IFYDNFODANQT2HMWSAOO6P6UKZZUCWSO2LNM2M6G7DUPGPLNH7HA@tmp:/var/lib/jenkins/workspace/oh-pr0009-api_master-IFYDNFODANQT2HMWSAOO6P6UKZZUCWSO2LNM2M6G7DUPGPLNH7HA@tmp:rw,z -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** 4d6ffe9d9713df374dd2670073b9ea32598df407 cat
      $ docker top 13d063e7996ad4476075baf7586aa3186d0bff08cdbd4c10205327bb6b44c75b -eo pid,comm
      ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument, as required by official docker images (see https://github.com/docker-library/official-images#consistency for entrypoint consistency requirements).
      Alternatively you can force image entrypoint to be disabled by adding option `--entrypoint=''`.
      

          [JENKINS-51307] Declarative pipeline and docker entrypoint

          Hey Jesse, I saw you were working on this plugin and took the liberty to assign you this issue. When I first opened it, I chose the wrong component. The right one is docker-workflow-plugin. Cheers

          Frederic Rousseau added a comment - Hey Jesse, I saw you were working on this plugin and took the liberty to assign you this issue. When I first opened it, I chose the wrong component. The right one is docker-workflow-plugin. Cheers

          Jesse Glick added a comment -

          As noted in the error message, this is not a valid entrypoint.

          Jesse Glick added a comment - As noted in the error message, this is not a valid entrypoint.

          It seems with these changes we are making things more complex. What could have been a simple purpose-built container to perform very specific task (regardless if ran on Jenkins or wherever) now requires extra scripting to meet https://github.com/docker-library/official-images#consistency

          I would argue that some containers used in pipelines will never become official.

          Anyways, I'd like to leave my solution here in case someone hits this issue:

          I used to have in my Dockerfile:

          ENTRYPOINT [ "python", "./my_script.py" ]
          

          To make it work, added a new script (`./entrypoint,sh`):

          #!/bin/sh
          set -e
          
          # check if there was a command passed
          # required by Jenkins Docker plugin: https://github.com/docker-library/official-images#consistency
          if [ "$1" ]; then
              # execute it
              exec "$@"
          fi
          
          # else run my script
          exec python ./my_script.py
          

          And changed the Dockerfile:

          ADD entrypoint.sh /
          
          ENTRYPOINT [ "/entrypoint.sh" ]
          

          You people are smart, you can come with nicer solutions. But I got that goin' for me, which is nice. Thanks jglick and others for all the hard work on this stuff!

          Michal Matyjek added a comment - It seems with these changes we are making things more complex. What could have been a simple purpose-built container to perform very specific task (regardless if ran on Jenkins or wherever) now requires extra scripting to meet https://github.com/docker-library/official-images#consistency I would argue that some containers used in pipelines will never become official. Anyways, I'd like to leave my solution here in case someone hits this issue: I used to have in my Dockerfile: ENTRYPOINT [ "python" , "./my_script.py" ] To make it work, added a new script (`./entrypoint,sh`): #!/bin/sh set -e # check if there was a command passed # required by Jenkins Docker plugin: https: //github.com/docker-library/official-images#consistency if [ "$1" ]; then # execute it exec "$@" fi # else run my script exec python ./my_script.py And changed the Dockerfile: ADD entrypoint.sh / ENTRYPOINT [ "/entrypoint.sh" ] You people are smart, you can come with nicer solutions. But I got that goin' for me, which is nice. Thanks jglick and others for all the hard work on this stuff!

          Jesse Glick added a comment -

          you can come with nicer solutions

          It is being worked on. The withDockerContainer step (including its agent docker Declarative sugar) should be avoided I think; it just never worked consistently enough to be an advertised feature.

          Jesse Glick added a comment - you can come with nicer solutions It is being worked on. The withDockerContainer step (including its agent docker Declarative sugar) should be avoided I think; it just never worked consistently enough to be an advertised feature.

          csanchez what do you think about this issue? docker maven doesn't work out of the box on declarative pipeline https://github.com/carlossg/docker-maven/ 

          mkj, your solution I find intrusive. I prefer to do the following to build my dockers. It's Ugly but the problem comes from Jenkins, I prefer to fix it in Jenkinsfile

              agent {
                  dockerfile {
                      args '--entrypoint=\'\''
                  }
              }
          

          Frederic Rousseau added a comment - csanchez what do you think about this issue? docker maven doesn't work out of the box on declarative pipeline https://github.com/carlossg/docker-maven/   mkj , your solution I find intrusive. I prefer to do the following to build my dockers. It's Ugly but the problem comes from Jenkins, I prefer to fix it in Jenkinsfile     agent {         dockerfile {             args '--entrypoint=\' \''         }     }

          Pieter Vogelaar added a comment - - edited

          Thanks zougi, I searched a lot on the internet and I finally found this Jira issue. I couldn't understand why nginx wasn't listening inside the container. But I guess Jenkins doesn't execute by default the entrypoint/CMD of de Docker image. This fixed it for me:

          customImage.inside("-u root --entrypoint='/start.sh'") {}
          

          Pieter Vogelaar added a comment - - edited Thanks zougi , I searched a lot on the internet and I finally found this Jira issue. I couldn't understand why nginx wasn't listening inside the container. But I guess Jenkins doesn't execute by default the entrypoint/CMD of de Docker image. This fixed it for me: customImage.inside( "-u root --entrypoint= '/start.sh' " ) {}

          Note that https://github.com/docker-library/official-images#consistency, point 3, says "If the image only contains the main executable and its linked libraries (ie no shell) then it is fine to use the executable as the ENTRYPOINT". So using cat as the command is not a valid consistency check.

          How can I just run the defined ENTRYPOINT, optionally passing arguments, but not have any steps defined?

          Sebastian Schuberth added a comment - Note that https://github.com/docker-library/official-images#consistency , point 3, says "If the image only contains the main executable and its linked libraries (ie no shell) then it is fine to use the executable as the ENTRYPOINT". So using cat as the command is not a valid consistency check. How can I just run the defined ENTRYPOINT, optionally passing arguments, but not have any steps defined?

          Jesse Glick added a comment -

          How can I just run the defined ENTRYPOINT, optionally passing arguments, but not have any steps defined?

          sh 'docker run --rm my-image some-arg'
          

          Jesse Glick added a comment - How can I just run the defined ENTRYPOINT, optionally passing arguments, but not have any steps defined? sh 'docker run --rm my-image some-arg'

          Tim Black added a comment - - edited

          sschuberth, regarding your comment on using `cat` as a docker command, I see in the OP and in my own pipeline examples that the `cat` command is specified at the end of `docker run` and I cannot figure out why. Any info would be helpful.

          For example, the following pipeline code:
           

          docker_image.inside("<other args>")  {   ... }

           
          results in the following docker run command, which has inserted a cat command at the end. 
           

          docker run -t -d -u 118:124 <other args...> <image-name> cat    

          I believe this might be the reason why when I specify a CMD and/or ENTRYPOINT in our Dockerfile, it isn't working. Perhaps this is inserted by Jenkins under some circumstance?

          UPDATE: I have since found this PR: https://github.com/jenkinsci/docker-workflow-plugin/pull/116 which discussion confirms the explicit forcing of CMD to `cat`.

          It is still woefully unclear to me how to specify, in a Dockerfile, how to run a command every time the docker image is run, when using Jenkins/Docker "inside()" pipeline.

          Tim Black added a comment - - edited sschuberth , regarding your comment on using `cat` as a docker command, I see in the OP and in my own pipeline examples that the `cat` command is specified at the end of `docker run` and I cannot figure out why. Any info would be helpful. For example, the following pipeline code:   docker_image.inside( "<other args>" )  {   ... }   results in the following docker run command, which has inserted a cat  command at the end.    docker run -t -d -u 118:124 <other args...> <image-name> cat     I believe this might be the reason why when I specify a CMD and/or ENTRYPOINT in our Dockerfile, it isn't working. Perhaps this is inserted by Jenkins under some circumstance? UPDATE: I have since found this PR:  https://github.com/jenkinsci/docker-workflow-plugin/pull/116  which discussion confirms the explicit forcing of CMD to `cat`. It is still woefully unclear to me how to specify, in a Dockerfile, how to run a command every time the docker image is run, when using Jenkins/Docker "inside()" pipeline.

          kenorb added a comment -

          I'm trying to run "philm/ansible_playbook" Docker imagewhich got ENTRYPOINT ["ansible-playbook"].

           

          I've got the following pipeline step:

           

                 stage('Ansible') {
                      agent {
                        docker {
                          image 'philm/ansible_playbook:latest'
                          alwaysPull true
                        }
                      }
                      environment {
                        ANSIBLE_HOST_KEY_CHECKING = false
                      }
                      steps {
                          sh "--version"
                      }
                  }
          

          But based on the "docker ps -a", it tries to run: "ansible-playbook cat" command and it fails.

           

          When I've changed the entrypoint as: args '--entrypoint=/bin/sh'  then it runs container as "/bin/sh cat" which doesn't make sense.

          Is there any normal way in pipeline of running container commands using original container's entrypoint?

          kenorb added a comment - I'm trying to run "philm/ansible_playbook" Docker image which got ENTRYPOINT ["ansible-playbook"] .   I've got the following pipeline step:   stage( 'Ansible' ) { agent { docker { image 'philm/ansible_playbook:latest' alwaysPull true } } environment { ANSIBLE_HOST_KEY_CHECKING = false } steps { sh "--version" } } But based on the "docker ps -a", it tries to run: "ansible-playbook cat" command and it fails.   When I've changed the entrypoint as:  args '--entrypoint=/bin/sh'   then it runs container as "/bin/sh cat" which doesn't make sense. Is there any normal way in pipeline of running container commands using original container's entrypoint?

            csanchez Carlos Sanchez
            zougi Frederic Rousseau
            Votes:
            8 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated: