`docker compose run --entrypoint=EXECUTABLE SERVICENAME` fails to clear CMD
BUG REPORT INFORMATION
Description
If I run a one-off container based on a service definition using the run subcommand and override the entrypoint, Compose 2.6.0 fails to clear the default command (default arguments to the default entrypoint) as well. As far as I can think of, every other Docker interface to override the entrypoint also clears CMD:
docker-compose runin v1- the
runsubcommand of Docker itself:
Note: Passing
--entrypointwill clear out any default command set on the image (i.e. anyCMDinstruction in the Dockerfile used to build it).
- Compose YAML files according to the Compose spec:
Compose implementations MUST clear out any default command on the Docker image - both
ENTRYPOINTandCMDinstruction in the Dockerfile - whenentrypointis configured by a Compose file.
- Older versions of the Compose YAML file format:
Note: Setting
entrypointboth overrides any default entrypoint set on the service’s image with theENTRYPOINTDockerfile instruction, and clears out any default command on the image - meaning that if there’s aCMDinstruction in the Dockerfile, it is ignored.
Steps to reproduce the issue:
- Define a service with both an entrypoint and a default command to pass to it, e.g.
services:
database:
image: mysql:8.0
command: ["--help"]
- Run a docker compose run command that overrides the entrypoint with a different executable, e.g.
$ docker compose run --rm --entrypoint=ls database
Describe the results you received:
The new entrypoint, ls, responds as if it was passed the default arguments intended for the original entrypoint, namely the --help, flag, and prints a usage message.`
Describe the results you expected:
I expected the new entrypoint, ls, to be run without arguments and list the files in the container's working directory.
Additional information you deem important (e.g. issue happens only occasionally):
None.
Output of docker compose version:
Docker Compose version v2.6.0
Output of docker info:
Snippet:
Client:
Context: default
Debug Mode: false
Plugins
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
compose: Docker Compose (Docker Inc., v2.6.0)
scan: Docker Scan (Docker Inc., v0.17.0)
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 10
Server Version: 20.10.17
[...]
Kernel Version: 5.4.0-121-generic
Operating System: Linux Mint 20.2
OSType: linux
Architecture: x86_64
[...]
Additional environment details:
—
Is there a suggested workaround for this?
It seems like this thread is possibly the same issue: https://github.com/docker/compose/issues/9483. But the suggested workaround there (using CMD in Dockerfile) doesn't provide the same functionality of being able to override with "command" at run-time, which I have been doing in a docker-compose.override.yml file to run a different command in development. This worked fine with v1, and I can't imagine why this is not a bug.
@totalhack:
Is there a suggested workaround for this?
If stuck with a Compose version that does not yet include the fix (releases prior to v2.11.2), I'd try to resolve it by looking if there's an argument that doesn't affect what the particular entrypoint command you're setting and explicitly set the command (=default arguments to the entrypoint) to that instead of expecting it to be empty. In the ls example I gave under Steps to reproduce, that could amount to replacing
$ docker compose run --rm --entrypoint=ls database
by
$ docker compose run --rm --entrypoint=ls database .
to effectively make the full command ls .. For some other commands, a single or double hyphen might be a good no-op argument list, if you're lucky.
@totalhack @fedde-s the release of Compose v2.11.2 done yesterday should fix the issue, no workaround needed it should work without overriding the command
Thank you very much for the quick resolution of the core issue, @glours and @milas!