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

Since 37987 images that use ENTRYPOINT for a reason cannot be used in testing

    Details

    • Similar Issues:

      Description

      The fix for the issues with maven in JENKINS-37987 broke workflows that have images where the container is run and the ENTRYPOINT is epxecxted to be used... one example being a container with systemd

      there should be a way to do something like:

      docker.image('foo').inside {
      sh 'make test'
      }
      

      and have the ENTRYPOINT still run

        Attachments

          Issue Links

            Activity

            Hide
            hogarthj James Hogarth added a comment -

            It was mentioned that an issue should be reopened as the actual problem behind it was fixed ... this is to properly track the regression in using images with an ENTRYPOINT in an inside() style manner

            Show
            hogarthj James Hogarth added a comment - It was mentioned that an issue should be reopened as the actual problem behind it was fixed ... this is to properly track the regression in using images with an ENTRYPOINT in an inside() style manner
            Hide
            hogarthj James Hogarth added a comment -

            https://github.com/jenkinsci/docker-workflow-plugin/pull/78 is an attempt to fix the broken workflow for those relying on ENTRYPOINT whilst using inside() by providing a new path of Image.exec()

            Show
            hogarthj James Hogarth added a comment - https://github.com/jenkinsci/docker-workflow-plugin/pull/78 is an attempt to fix the broken workflow for those relying on ENTRYPOINT whilst using inside() by providing a new path of Image.exec()
            Hide
            hrmpw Patrick Wolf added a comment -

            Andrew Bayer has PR-85 that reverts the change and adds a method to override entrypoint. The change in PR-63 forced an entrypoint override.

            IMO, the problem with the approach in PR-63 is that you cannot respect entrypoint defined in an image. If we revert the change back to use cmd instead of entrypoint to run the inside commands it will respect the image's entrypoint. If you want to override the image's entrypoint you can still use this command:

            docker.image("my-image").inside("--entrypoint cat") {}
            

            The above should give the same behavior as the current 'docker.inside'

            We should let the user decide if they want to override the image's entrypoint instead of forcing this behavior.

            Show
            hrmpw Patrick Wolf added a comment - Andrew Bayer has PR-85 that reverts the change and adds a method to override entrypoint. The change in PR-63 forced an entrypoint override. IMO, the problem with the approach in PR-63 is that you cannot respect entrypoint defined in an image. If we revert the change back to use cmd instead of entrypoint to run the inside commands it will respect the image's entrypoint. If you want to override the image's entrypoint you can still use this command: docker.image( "my-image" ).inside( "--entrypoint cat" ) {} The above should give the same behavior as the current 'docker.inside' We should let the user decide if they want to override the image's entrypoint instead of forcing this behavior.
            Hide
            cleclerc Cyrille Le Clerc added a comment -

            Thank you very much!

            Show
            cleclerc Cyrille Le Clerc added a comment - Thank you very much!
            Hide
            erictankok Eric Tan added a comment - - edited

            Agree with Patrick that the user should decide if they want to override the image's entrypoint.

            Using Jenkins 2.79 and as shown below in the console output, Jenkins adds "--entrypoint cat" which overrides my own entrypoint.
             
            $ docker run t -d -u 1000:1000 -w /var/jenkins_home/workspace/ Test_Pipeline_master-K2ZSF4WTA --volumes-from db477ccfb5f8261f85de03 -e ******** -e ******** -e ******** -entrypoint cat test-app  
             
            docker inspect shows:              
            "Entrypoint": [
                            "cat"
            ],
             
            The original image is:
            "Entrypoint": [
                      "python",
                            "test-app.py"
            ],

            Show
            erictankok Eric Tan added a comment - - edited Agree with Patrick that the user should decide if they want to override the image's entrypoint. Using Jenkins 2.79 and as shown below in the console output, Jenkins adds " --entrypoint cat " which overrides my own entrypoint.   $ docker run t -d -u 1000:1000 -w /var/jenkins_home/workspace/ Test_Pipeline_master-K2ZSF4WTA --volumes-from db477ccfb5f8261f85de03 -e ******** -e ******** -e ******** -entrypoint cat test-app     docker inspect shows:               "Entrypoint": [                 "cat" ],   The original image is: "Entrypoint": [           "python",                 "test-app.py" ],
            Hide
            bitgandtter Yasmany Cubela Medina added a comment -

            Im experiencing this issue, i have a test image with an specific ENTRYPOINT and now its been ignored and cat its been used instead which leads to failure.

            Show
            bitgandtter Yasmany Cubela Medina added a comment - Im experiencing this issue, i have a test image with an specific ENTRYPOINT and now its been ignored and cat its been used instead which leads to failure.
            Hide
            amirbarkal Amir Barkal added a comment -

            +1 on this issue. 
            Suffering the same error with a Docker image that specifies an ENTRYPOINT.

            Show
            amirbarkal Amir Barkal added a comment - +1 on this issue.  Suffering the same error with a Docker image that specifies an ENTRYPOINT.
            Hide
            andrewnicols Andrew Nicols added a comment -

            This issue is also duplicated yb 49278 and 54389.
            What can we do to work towards getting this issue resolved?

            The ENTRYPOINT and CMD in the Dockerfile should be respected. The docker-workflow plugin should be running the images, not changing their nature.

            Can we instead look at using the Docker healthcheck functionality if a healthcheck is provided?

            Show
            andrewnicols Andrew Nicols added a comment - This issue is also duplicated yb 49278 and 54389. What can we do to work towards getting this issue resolved? The ENTRYPOINT and CMD in the Dockerfile should be respected. The docker-workflow plugin should be running the images, not changing their nature. Can we instead look at using the Docker healthcheck functionality if a healthcheck is provided?

              People

              • Assignee:
                hogarthj James Hogarth
                Reporter:
                hogarthj James Hogarth
              • Votes:
                15 Vote for this issue
                Watchers:
                23 Start watching this issue

                Dates

                • Created:
                  Updated: