Support --no-recreate flag in docker-compose run

[villesau]

Description

Looks like on CircleCI docker-compose recreates database containers if there are multiple subsequent docker-compose run commands run. However, this is not desirable since the first run is for running the migrations and the second one is for running the tests, both in different services but same docker-compose file.

Steps to reproduce the issue:

1. run migrations via docker-compose -f compose/test.yml run backend ./wait-for test-db:5432 -- npm run db:seed:test
2. run tests via docker-compose -f compose/test.yml run mocha
3. Second run gives following kind of output:

 [+] Running 2/2
  ⠿ Container tests-test-redis-1    Recreated 0.2s
  ⠿ Container tests-test-db-1       Recreated 0.3s
  ⠋ Container tests-test-backend-1  Creating 0.0s

Describe the results you received:

 [+] Running 2/2
  ⠿ Container tests-test-redis-1    Recreated 0.2s
  ⠿ Container tests-test-db-1       Recreated 0.3s
  ⠋ Container tests-test-backend-1  Creating 0.0s

Describe the results you expected:

I'm expecting the containers not to be recreated so that I can first run migrations and then the tests. This is how it worked in docker-compose v1.

Additional information you deem important (e.g. issue happens only occasionally):

docker-compose v1 worked differently and the containers were not recreated, which is desirable in cases like this. There is also discrepancies between CircleCI ubuntu image running docker-compose v2 & macOS. on macOS everything works, on CircleCI stuff is recreated. I'd like unified experience across the platforms.

There is also no clear documentation that would tell in which cases containers are recreated, created or reused.

Some further info in this question: https://stackoverflow.com/questions/72583887/docker-compose-v2-run-command-recreates-containers

Output of docker compose version:

Docker Compose version v2.2.3

Additional environment details:

[hwo411]

We also faced this issue. The workaround that we use:

docker compose run --rm container_name true - to start all dependencies then you can e.g., load database schema

And then run your tests with --no-deps: docker compose run --no-deps --rm container_name your_test_command

Hope that helps!

[ndeloof]

Could you please confirm this issue still is relevant with latest release ? What you describe here is the expected behavior, and AFAICT this is what we get with latest release v2.17.3

[ndeloof]

I wonder this unexpected "recreate" issue is the same as https://github.com/docker/compose/pull/10540

[faustind]

The issue seems to be related to the interpretation of depends_on.

I ran into the same trouble.

With --no-deps, the dependencies will not be created if they do not already exist.

I would propose that dependencies are not recreated if they are already running. Such behavior would align with the specified behavior of depends_on which is to "start services in dependency order". I think it's natural not to restart services that are already running.

The adjustment I propose would keep consistency with the behavior in compose V1.

[ndeloof]

I would propose that dependencies are not recreated if they are already running

this is the expected behavior, if not there's a bug comparing desired and actual state, comparable to https://github.com/docker/compose/pull/10540

[faustind]

@ndeloof Are you saying that the expected behavior is "dependencies are not recreated if they are already running"?

[ndeloof]

@faustind yes. docker compose run should use existing services previously set by up

example:

services:
   web:
      image: nginx
   test:
      image: alpine
      command: ping -c 1 web
      depends_on:
        - web

$ docker compose up -d web
[+] Running 1/1
 ✔ Container machin-web-1  Started                                                                                                   0.4s 
$ docker compose run test
[+] Creating 1/0
 ✔ Container machin-web-1  Running                                                                                                   0.0s 
PING web (172.19.0.2): 56 data bytes
64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.540 ms

note ^ web container is Running and has not been recreated. If this isn't what you get, then there's a bug (possibly fixed by https://github.com/docker/compose/pull/10540)