Docker Compose support does not work in AOT-processed tests

[wilkinsona]

This can be reproduced using Petclinic's tests with AOT enabled:

tasks.named('test') {
  useJUnitPlatform()
  systemProperty "spring.aot.enabled", true
}

./gradlew test fails with both tests in PostgresIntegrationTests failing as they could not connect to Postgres. They try to use the default host and port rather than those of a container starter by Docker Compose.

[roxspring]

Any idea what needs to be done to fix this? Failing the PetClinic Gradle build because Docker isn't available seems really odd - I didn't think Docker was a hard requirement?

[scottfrederick]

Docker Compose support is explicitly disabled when spring.aot.enabled is true:

spring-boot/spring-boot-project/spring-boot-docker-compose/src/main/java/org/springframework/boot/docker/compose/lifecycle/DockerComposeLifecycleManager.java

Lines 97 to 100 in 3c00bf3

	if (Boolean.getBoolean("spring.aot.processing") || AotDetector.useGeneratedArtifacts()) {
	logger.trace("Docker Compose support disabled with AOT and native images");
	return;
	}

We could potentially change AotDetector.useGeneratedArtifacts() there to NativeDetector.inNativeImage() to fix this problem, but there's some history behind that in #35548 and #35676 and I'm not sure what other side-effects making that change would have.

[wilkinsona]

Thanks, Scott. #35548 and #35676 were about preventing the Docker Compose support from breaking things by getting it to back off when AOT processing or building a native image. This issue's about removing the need for that by getting it to work after AOT processing or in a native image.

The failure that I described (not very clearly) above is occurring because the Docker Compose support has backed off, leaving the tests looking for a DB on its default host and port rather than from a Compose-managed container. If we can get this to work after AOT processing or in a native image then I think we can safely stop making the support back off in those situations.

[herder]

Will this mean that we can never build projects using Docker Compose for integration tests with AOT processing?

Or maybe I'm misunderstanding the issue?

We have quite a few projects where it's important we run the ITs against the same PG version as in prod, so I'd love to be wrong :)

[wilkinsona]

It should be fine, unless you want to AOT-process your tests. Generally speaking, I wouldn't recommend that unless you want to run the tests in a native image.