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

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()

abayer 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.

Thank you very much!

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"
],

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.

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

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?