Docker backend shouldn't assume to know the entrypoint when running commands

[jcmcken]

When using the run method for the Docker backend, sh -c is hard-coded as the entrypoint, which overwrites the entrypoint defined in the image.

In my specific case, the entrypoint is overridden for a particular image to an alternate shell. testinfra uses the default shell, which causes my tests to break.

The entrypoint should be configurable or else not hard-coded at all so that the image's entrypoint takes precedence.

[philpep]

Hi, thanks for report !

Having a valid shell as entrypoint for commands is required to have all testinfra modules works. Maybe we need kind of docker module (or in the existing Command module) that run entrypoint with supplied arguments. Is it possible with docker exec ? (Since testinfra expect the container to be running).

[jcmcken]

Sorry, it looks like this is a limitation of Docker itself. The entrypoint and environment are only created on the runtime process of the container. Any subsequent exec calls are new processes, and don't get the same entrypoint, etc. It doesn't seem like there's a built-in way to easily attach to the runtime process with the same settings.

The only real way to be able to test the runtime behavior (env, etc.) of a container would be to issue the test command with the docker run, rather than launching a container in the background and issuing docker execs against it.

So I guess this particular issue could be closed as written, but I wonder if there's room for a feature request to be able to issue test commands via docker run (new container for each command) rather than docker exec.