docker
Add "--wait" to "docker compose run"
Description
The docker compose run command supports the --detach option to run a one-off container in the background.
However, there is no --wait option so e.g. following one-off containers trying to connect to a service in the initially launched containers may fail or need to manually wait for the connection to be ready. With docker compose up there is a --wait option which ensures that containers are fully started and healthy in case a healthcheck is defined.
To be consistent and provide a good DX, --wait should be added to docker compose run, too.
docker compose run is intended to mimic docker run
Any reason you don't use docker compose up --wait SERVICE to get this feature ?
up has less options to override configuration compared to run, e.g. --volume or, well, the command to run. One can bypass this limitation with additional Compose files to be loaded, however run supports many options natively. This also simplifies e.g. CI log output where one can directly see a CLI invocation but needs additional steps to debug and merge additional Compose files.
And again, it would simply make sense from the consistency POV.
Also since there is no docker up, comparing docker compose run with docker run is not really useful IMO. E.g. the native concept of "wait" is not present in docker whereas it is implemented in many useful places in docker compose. So my suggestion is to extend this implementation once more.
We don't consider this a legitimate addition to run command, as up already covers this usage. Ability to override command by command line argument can easily be replaced by either variables in compose.yaml of a dedicated override file for command.
comparing docker compose run with docker run ...
compose run is by design aligned with docker run. Just consider this a custom flavor of docker run passing all flags as yaml
I understand the reasoning.
And providing a command in Compose may solve this: I can run docker compose up service-with-command which will automatically wait for dependencies of the service-with-command.