Docker rate limits reached in BootBuildImageIntegrationTests

[dreis2211]

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

[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.

[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.

[dreis2211]

The latest round failed in more places: https://ge.spring.io/s/4dujcww2bgf2g

[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.

[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.