compose: docker-compose run --rm does not rm links

I was expecting docker-compose run --rm to also clean up linked containers if it created them. This would be really helpful when running integration tests in build environments.

What I would like to do:

#!/bin/bash -eu

# other commands here

docker-compose run --rm dotnet dotnet test

What I’m currently stuck doing:

#!/bin/bash -eu

# other commands here

set +e
docker-compose run --rm dotnet dotnet test
exitcode=$?
if [ $exitcode -ne 0 ]; then
    docker-compose down
    exit $exitcode
fi
set -e

Could you please reopen this?

As mentioned in this thread, docker-compose rm -f --all and docker-compose down already allow cleaning up a project’s containers / resources. We won’t overload run with more options at that point.

I know this thread is probably DOA, but any chance of reviving the discussion? I find it hard to comprehend that in the same post where it’s stated

I’m wary of adding even more behavior to run, even if optional. It’s already quite complicated.

it’s also stated

The fact that it automatically starts dependencies was intended as a convenience so you don’t have to run docker-compose up -d beforehand.

So, why are we fine including a convenience in only one half of the equation? If this is not the desired use, then shouldn’t we remove the convenience at the start, rather than refuse to include it at the end?

I feel we should either complete the circle or not allow people to fall into this trap and remove the convenience of the implicit “up”

+1 for removing linked containers somehow using run command.

IMHO, This ticket can be closed

Dunno. Running builds, e.g. using docker-compose run --rm .... is a great use case. I use it for Java and Go and any lang that needs to compile a deployment artifact, then use my Dockerfile to build my final image using that artifact.

If my build has a dependency, e.g. testing needs a database or three, then the compose file makes a great way to spin it up automatically.

But, when compose removes my one-time run via run --rm, it leaves the other services up.

At the very least, would be good if I could say, run --rm-all or similar, so it would know to start and stop all.

Just adding my +1. If a “run” command is responsible for creating linked containers “for convenience” then it should similarly clean up after itself “for convenience”.

Note that, as others have said, it should only take down containers that were spun up to facilitate the command. If the containers were already up then they should remain so.

Yes, that is my use case. It is quite convenient for running automated functional tests (i.e.: jmeter) as part of a continuous integration pipeline.

You need to support docker-compose --rm up --build

😃

run is used for a lot of different things, but its primary designed use case is running a one-off command against a long-running dev environment. The fact that it automatically starts dependencies was intended as a convenience so you don’t have to run docker-compose up -d beforehand.

@breerly, @theypsilon: it sounds like your use case is more like spinning up a multi-container environment purely for the purpose of running a single container which depends on that environment, capturing the output of that container, and then cleaning up the entire environment. Is that right?

If so, it’s not really what run is for. You can certainly do it, it’s just a little more work on your side to run the cleanup after the command. Off the top of my head, this should do it (not tested):

#!/bin/bash
# Usage: run.sh SERVICE [CMD...]

docker-compose run --rm "$@"
exit_code=$?
docker-compose down
exit $exit_code

I’m wary of adding even more behaviour to run, even if optional. It’s already quite complicated.

Also would like --rm to remove linked containers.

Is there any plan for docker-compose run mycontainer --down then?