Entrypoint rewriting logic is ignoring cmd

[bobcatfish]

Expected Behavior

I'm a bit confused about this to tell you the truth, but I think think that when we are wrapping a container, we should be respecting both the entrypoint and the cmd

Actual Behavior

When we retrieve an image's entrypoint we do just that - we get the entrypoint only and ignore the cmd. So if an image is relying on the cmd to do the right thing, we wipe it out and completely ignore it.

Steps to Reproduce the Problem

1. Create a Task with a step that tries to rely on an image's cmd, e.g. in this case the cmd for the golang image is go, so we shouldn't need to specify that explicitly,:

  - name: install-ko
    image: golang
    args:
    - "get"
    - "github.com/google/go-containerregistry/cmd/ko"

2. Create a TaskRun that uses the above. It will fail with an error like:

could not start the process: exec: \"get\": executable file not found in $PATH

3. If you update the step to use go explicitly, it will work:

  - name: install-ko
    image: golang
    command: ["go"]
    args:
    - "get"
    - "github.com/google/go-containerregistry/cmd/ko"

Additional Info

• For reference: https://stackoverflow.com/questions/21553353/what-is-the-difference-between-cmd-and-entrypoint-in-a-dockerfile
• Note that in Changing build steps from initContainers to Containers #564 @pivotal-nader-ziada is updating this logic

[nader-ziada]

/assign

[nader-ziada]

in pr #564, I have logic that will check the remote image entrypoint and if there isn't one, will check the cmd
would that cover the problem you ran into?

[abayer]

Oh boy, this is always a fun area - we've flip-flopped on how the Jenkins/Docker integration works from using entrypoint vs cmd...well, multiple times. The lesson I've taken away from our pain there is that if you try to handle every particular permutation of entrypoint vs cmd as default behavior, you're going to have a bad time. My opinion is that it's best to settle on one expected/required behavior, and just accept that this means some images will require a bit more configuration to use. Our situation here seems to be much simpler than the Jenkins/Docker concerns, though, so I may just be paranoid. =)

[nader-ziada]

@bobcatfish I think this should be closed as part of the changes in PR #564

[dlorenc]

Fixed with #564