Repository navigation
Docker Compose support does not work in AOT-processed tests #36273
Description
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.
Activity
roxspring commentedon Dec 5, 2023
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 commentedon Apr 26, 2024
Docker Compose support is explicitly disabled when
spring.aot.enabledistrue: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
We could potentially change
AotDetector.useGeneratedArtifacts()there toNativeDetector.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 commentedon Apr 29, 2024
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 commentedon Sep 29, 2025
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 commentedon Sep 29, 2025
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.
herder commentedon Sep 29, 2025
Got it - thanks for the clarification!
Support Docker Compose in AOT-processed tests
goutamadwant commentedon Aug 6, 2026
@wilkinsona I’ve opened #51287 to address this issue.
So the change allows Docker Compose connection details to participate in test AOT processing while preserving the existing backoff for application AOT processing. The temporary connection details are excluded from generated registrations and recreated when the AOT-processed test runs. Let me know if this looks good or any suggestions! thanks.
tchowdhury101 commentedon Nov 3, 2026
Hi, I'd like to work on this. Is it open for contribution?