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

Images that specify an entrypoint can not be used as a build environment

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Steps:

      1. Create an image that specifies an entrypoint in the Dockerfile, e.g.:
      ENTRYPOINT [ "/usr/share/maven/bin/mvn" ]
      2. Create a build job that uses the image as a Build Environment

      When the environment is started docker run passes "cat" as a command but does not override the entry point. The result is that "/usr/share/maven/bin/mvn cat" is invoked in the container which typically fails causing the whole build to fail with an unexpected error.

      There is no configuration option to specify the entrypoint for the Build Environment.

        Attachments

          Activity

          Hide
          ndeloof Nicolas De Loof added a comment -

          According to Docker best practices, entrypoint should be designed to detect it is used to run a single command, and not just pass additional arguments.
          If you use Entrypoint this way, then your Docker image is designed to run a standalone service, not to be used as a build environment. Just adjust your Docker image to your needs.

          Show
          ndeloof Nicolas De Loof added a comment - According to Docker best practices, entrypoint should be designed to detect it is used to run a single command, and not just pass additional arguments. If you use Entrypoint this way, then your Docker image is designed to run a standalone service, not to be used as a build environment. Just adjust your Docker image to your needs.
          Hide
          mgreau Maxime GREAU added a comment -

          I'm blocked with the same case and I found this issue, cool.
          But I'm not agree with the resolution .

          So in our case we try to use the simplest (and same) commands for developers and CI environment.

          That's why we have created some Docker CI images for each stack (JDK8/Maven32, JDK6/Maven30...) with
          the following Dockerfile commands:

          ...
          ENTRYPOINT ["mvn"]
          CMD ["--help"]
          

          https://github.com/exo-docker/exo-ci/blob/master/jdk8-maven32/Dockerfile#L50-L51

          So now we can easily build our legacy or newest projects without all Maven and JDK versions installed locally, with the following command:

          $ cd my-project
          $ docker run --name=my-project-build -it -v $(pwd):/opt/ciagent/workspace \
               -v ~/.m2/repository:/opt/ciagent/.m2/repository \
               -v ~/.m2/settings.xml:/opt/ciagent/.m2/settings.xml \
               exoplatform/ci:jdk8-maven32 clean package
          

          According to the official Docker documentation and best practices, such use of ENTRYPOINT and CMD Dockerfile commands seems to be the
          good one:

          WDYT? (cc Nicolas De Loof )

          Show
          mgreau Maxime GREAU added a comment - I'm blocked with the same case and I found this issue, cool. But I'm not agree with the resolution . So in our case we try to use the simplest (and same) commands for developers and CI environment. That's why we have created some Docker CI images for each stack (JDK8/Maven32, JDK6/Maven30...) with the following Dockerfile commands: ... ENTRYPOINT [ "mvn" ] CMD [ "--help" ] https://github.com/exo-docker/exo-ci/blob/master/jdk8-maven32/Dockerfile#L50-L51 So now we can easily build our legacy or newest projects without all Maven and JDK versions installed locally, with the following command: $ cd my-project $ docker run --name=my-project-build -it -v $(pwd):/opt/ciagent/workspace \ -v ~/.m2/repository:/opt/ciagent/.m2/repository \ -v ~/.m2/settings.xml:/opt/ciagent/.m2/settings.xml \ exoplatform/ci:jdk8-maven32 clean package According to the official Docker documentation and best practices, such use of ENTRYPOINT and CMD Dockerfile commands seems to be the good one: https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#entrypoint https://docs.docker.com/engine/reference/builder/#entrypoint WDYT? (cc Nicolas De Loof )
          Hide
          ndeloof Nicolas De Loof added a comment -

          on https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#entrypoint you have sample for postgres entrypoint script, which detect a valid postgres command or switch to plain `$@` execution. This is actually a requirement for official docker image to let user run with `bash` (or any other) command and execute it in replacement for the packaged tool.

          Also see https://github.com/jenkinsci/docker/blob/master/jenkins.sh#L32
          will be harder with maven as the argument is a maven phase, which can be arbitrary string :-\

          possible workaround : give up with this plugin and use docker-slaves !

          Show
          ndeloof Nicolas De Loof added a comment - on https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#entrypoint you have sample for postgres entrypoint script, which detect a valid postgres command or switch to plain `$@` execution. This is actually a requirement for official docker image to let user run with `bash` (or any other) command and execute it in replacement for the packaged tool. Also see https://github.com/jenkinsci/docker/blob/master/jenkins.sh#L32 will be harder with maven as the argument is a maven phase, which can be arbitrary string :-\ possible workaround : give up with this plugin and use docker-slaves !
          Hide
          ndeloof Nicolas De Loof added a comment -

          Maxime GREAU I guess you could detect a command to be executed in replacement to a maven goal if it starts with '/'.
          plugin do actually run `/bin/cat`, and this is a reasonable constraint for user to provide full executable path if they want to bypass the entrypoint

          Show
          ndeloof Nicolas De Loof added a comment - Maxime GREAU I guess you could detect a command to be executed in replacement to a maven goal if it starts with '/'. plugin do actually run `/bin/cat`, and this is a reasonable constraint for user to provide full executable path if they want to bypass the entrypoint

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              spingel Steffen Pingel
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: