SpringBoot Docker Compose support does not work in AOT-processed tests

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.

Comment From: 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?

Comment From: scottfrederick

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

https://github.com/spring-projects/spring-boot/blob/3c00bf367d7b03d8b8e005e8097c295996290b59/spring-boot-project/spring-boot-docker-compose/src/main/java/org/springframework/boot/docker/compose/lifecycle/DockerComposeLifecycleManager.java#L97-L100

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.

Comment From: 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.