Hi,
I think BootBuildImageIntegrationTests needs to be revisited again. It's hitting Docker's rate limits on CI: https://ge.spring.io/s/ratf3z65ld4wk/tests/:spring-boot-project:spring-boot-tools:spring-boot-gradle-plugin:test/org.springframework.boot.gradle.tasks.bundling.BootBuildImageIntegrationTests/buildsImageWithPullPolicy()%5B4%5D#1
Cheers, Christoph
Comment From: scottfrederick
In the 2.4.x and 2.5.x branches, most tests set pullPolicy=IF_NOT_PRESENT to minimize the number of times the test builder image is pulled from Docker Hub. With this latest round of rate-limit errors, all tests failures were in the one test (BootBuildImageIntegrationTests.buildsImageWithPullPolicy()) that forces the builder image to be pulled to verify that the pullPolicy option is working correctly. I'm not sure how much more we can do in the tests to reduce the chances of hitting rate limits.
We are investigating adding infrastructure to the Spring CI to proxy images from Docker Hub to help alleviate rate limits in builds across all Spring projects. In the interim we'll continue to monitor the situation.
Comment From: dreis2211
@scottfrederick My naive idea was to pull out BootBuildImageIntegrationTests.buildsImageWithPullPolicy() of the GradleCompatibility build and just test with one Gradle version. The combinations with configuration-cache on and off have extended the variations quite a bit - and therefore the pressure on rate limits.
Comment From: dreis2211
The latest round failed in more places: https://ge.spring.io/s/4dujcww2bgf2g
Comment From: scottfrederick
Yes, we are aware and are monitoring it. All projects building on ci.spring.io share the same rate limits so it's likely there's an unusually high level of contention right now.
Comment From: scottfrederick
Closing this issue in favor of re-opening #25838 to investigate why the custom builder image pulls are behaving differently than Paketo image pulls.