java-build fails when Maven Central rate-limits the runner:
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-source-plugin/3.3.1/maven-source-plugin-3.3.1.pom
[ERROR] Plugin org.apache.maven.plugins:maven-source-plugin:3.3.1 or one of its dependencies could not be resolved:
[ERROR] Could not transfer artifact org.apache.maven.plugins:maven-source-plugin:pom:3.3.1 from/to central
(https://repo.maven.apache.org/maven2): status code: 429, reason phrase: Too Many Requests (429)
Seen on #1778, job 98682899970. The artifact exists; the request was throttled. The build spent ~76s retrying and then failed the whole job before compiling any cuOpt code, so this fails PRs for reasons unrelated to their contents.
This will get more frequent, not less: the job runs on every PR touching test_cpp or test_java (.github/workflows/pr.yaml), every run resolves the full plugin and dependency set from Central with no local cache, and shared CI egress IPs are exactly what Central throttles.
Possible fixes
- Cache
~/.m2/repository between runs, so a warm cache does not hit Central at all
- Point
settings.xml at an internal mirror or a caching proxy rather than Central directly
- Configure Maven's Wagon retry/backoff (
-Dmaven.wagon.http.retryHandler.count, httpconnectionManager.ttlSeconds) so a 429 is retried rather than fatal
- Pre-populate the dependencies in the
rapidsai/ci-conda image used by the job
The first two remove the dependency on Central being reachable and unthrottled on every run; the third only softens the symptom.
Reproducing
Not reliably reproducible on demand, since it depends on Central's throttling of the runner's egress IP at that moment. It shows up as an intermittent java-build failure with a 429 in the log, distinguishable from a genuine dependency problem by the status code.
java-buildfails when Maven Central rate-limits the runner:Seen on #1778, job 98682899970. The artifact exists; the request was throttled. The build spent ~76s retrying and then failed the whole job before compiling any cuOpt code, so this fails PRs for reasons unrelated to their contents.
This will get more frequent, not less: the job runs on every PR touching
test_cpportest_java(.github/workflows/pr.yaml), every run resolves the full plugin and dependency set from Central with no local cache, and shared CI egress IPs are exactly what Central throttles.Possible fixes
~/.m2/repositorybetween runs, so a warm cache does not hit Central at allsettings.xmlat an internal mirror or a caching proxy rather than Central directly-Dmaven.wagon.http.retryHandler.count,httpconnectionManager.ttlSeconds) so a 429 is retried rather than fatalrapidsai/ci-condaimage used by the jobThe first two remove the dependency on Central being reachable and unthrottled on every run; the third only softens the symptom.
Reproducing
Not reliably reproducible on demand, since it depends on Central's throttling of the runner's egress IP at that moment. It shows up as an intermittent
java-buildfailure with a 429 in the log, distinguishable from a genuine dependency problem by the status code.