[BUG] docker compose up --no-deps recreates container

[RicardoM17]

Description

If we have a compose file with two services A and B, where B depends_on A then the following used to be the scenario.

1. docker compose up -d would start both service-a and service-b as expected.

If afterwards we ran

2. docker compose up -d service-b then nothing would happen. We'd just get container service-b Running.

This was true until at least Docker Compose version v2.15.1. However at least from Docker Compose version v2.26.0 when running command 2 above we recreate service-b even if nothing actually changed. This is also the case with the latest compose version v2.29.2.

3. Running docker compose up -d will recreate service-b again which, again, didn't use to happen.

I had a look and I suspect that this happens because when starting a container with no-deps, the com.docker.compose.depends_on label is now empty, when before it wasn't. I think that this is the diff that causes the container to be recreated.

So this seems to be an unintended regression and it does make docker compose rather more finicky than before so hopefully it can be fixed.

Steps To Reproduce

No response

Compose Version

No response

Docker Environment

No response

Anything else?

No response

[ndeloof]

The root cause is that we use a mutated ServiceConfig with depends_on definition removed when running --no-deps, which changes the service config hash. I'm investigating for a fix

[RicardoM17]

Thanks for the quick reply @ndeloof

If you do find a fix and compile a version that I can download from this repository I can help confirm that the issue is resolved from my side but it also seems rather simple to reproduce.

Let me know if I can help in other way. If not I'll just wait 🤞

[jhrotko]

Olá @RicardoM17, :)

Could you please try with the new compose version so that we know the merged PR fixed your issue? If so, please feel free to close this issue

[RicardoM17]

Olá @jhrotko !

I commented on the PR issues and yes it solves the bug in question. The fix is already pulled and deployed on our side. I thought this issue would get closed once the PR was merged or released so I'll do it now.

Thank you once again to both of you.