DockerComposeContainer does not work with local docker-compose v2

[ratcashdev]

Upgrading the host's docker-compose to v2 (as it just happened on Manjaro stable) breaks testcontainers compose module
if .withLocalCompose(true) is set.

I 2021-10-08T21:26:58,503 🐳 [docker-compose] Container br9dj5ov1knh-my-image-1  Started [Thread-1]
I 2021-10-08T21:26:58,508 🐳 [docker-compose] Docker Compose has finished running [main]
I 2021-10-08T21:26:58,916 ?.7.3.4-r0] Creating container for image: alpine/socat:1.7.3.4-r0 [main]
E 2021-10-08T21:26:58,945 ?.7.3.4-r0] Could not start container [main]
org.testcontainers.containers.ContainerLaunchException: Aborting attempt to link to container ttytbebgfezl_my-image_1 as it is not running
	at org.testcontainers.containers.GenericContainer.applyConfiguration(GenericContainer.java:812) ~[testcontainers-1.16.0.jar:?]
	at org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:363) ~[testcontainers-1.16.0.jar:?]
	at org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:329) ~[testcontainers-1.16.0.jar:?]

OS: Manjaro Linux
Compose version: Docker Compose version 2.0.1

[kiview]

Hi @ratcashdev,
thanks for reporting this issue, I can confirm on Docker Desktop for Windows as well.

Is using .withLocalCompose(false) (the default) a usable workaround for you?

#3468 might also be related to docker-compose v2.

[ratcashdev]

Unfortunately I find it difficult to use the built-in compose support because of authentication (and therefore pull) issues.

[kiview]

Authenticated pull should work with DockerComposeContainer in recent Testcontainers versions. Feel free to create a separate issue if you have any problems with this approach.

[ratcashdev]

Yes, I checked the docs, but It does not seem a drop-in replace and I'd rather avoid making changes to all the CI pipelines.
Wonder what kind of effort would it be to make this module work with compose v2 instead.

[nicklascarnegie]

This is happening with all versions of Docker Desktop > 4.0.1 on macOS (Big Sur 11.6) as well.

[kiview]

This happens with all Docker Desktop versions, that bundle Compose V2.

Classic Docker Compose V1 is not yet deprecated and at least in Docker for Windows, you can enable it in the Docker settings:

[snemarch]

Would it be possible to support both dash and hyphen container naming? V1 might not have been deprecated, but with how Docker pushes updates and doesn't seem to care too much about breaking backwards compatibility... 😅

I think it would be OK having a withXxx method in DockerComposeContainer for selecting, rather than autodetecting compose version, but I'm not sure if it should be something like withComposeV2ServiceName() or withServiceNamePartSeparator('-'), or an entirely different approach.

[joachimglink]

A workaround to get DockerComposeContainer working when docker compose v2 is enabled is to set
withOptions("--compatibility");

[dboreham]

I just ran into this. It seems that modern docker (no hyphen) compose is showing up more and more. It burned me in a CI environment that unknown to me switched to new docker leading to my testcontainers-based tests failing in this weird way.

Would it be worthwhile me attempting to fix this with a PR? Is anyone else working on this?

[eddumelendez]

#5608 adds support to compose v2 which will be released in the next version.

[rahulagrawal]

Thank You. This helped to solve my issue. I was using a mix of private and public images to be pulled.
Opted for withLocalCompose(true) to get the authentication working in the easiest mode as per the doc at https://java.testcontainers.org/modules/docker_compose/#using-local-compose-mode

Containers were not coming up properly. Using the compatibility flag, I have been able to move ahead.
I am using the latest version of Test containers and Docker Desktop on mac.