Repository navigation
Use of mvnw on CI seems flaky #9493
Description
Since I changed the workflows to use mvnw consistently, I've noticed builds seem to flake reasonably frequently, which is a waste of people's time.
Not sure exactly why, possibly due to newer rate limiting, maybe compounded by lack of caching in the workflow, but maven/Apache don't seem to publish their non-latest builds to a decent CDN for some reason.
I should probably look at it and find an improvement if no-one else gets to it.
Activity
headius commentedon Jul 8, 2026
I have noticed it failing occasionally as well. Taking five minutes to research it.
headius commentedon Jul 8, 2026
We might have better luck using the main Maven Central URL to download, which I believe is mirrored and federated across a number of servers:
https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.9.16/apache-maven-3.9.16-bin.zip
We might also be able to add caching for the wrappers to our builds (using a simple cache key based on the version, perhaps), or get the setup-java action to add wrapper caching by default into the
cache: mavenhandling.chadlwilson commentedon Jul 8, 2026
Oh < if they publish dists to maven central I wonder why they don't use that, given issues on their own infra.... That'd be a quick win.
The wrappers are just using scripts now, so nothing binary to cache there now, plus setup-java already caches the distributions if enabled with
mavenstyle: https://github.com/actions/setup-java#caching-packages-dependenciesI didn't actually check the workflows, but I imagined the problem with naively adding caching everywhere may be bad cache keys if anything polyglot is downloading stuff into the Maven cache. But didn't spend any time yet.
headius commentedon Jul 8, 2026
The wrapper fetches maven to
~/.m2/wrappersso that would be the additional location to cache across runs. Since only downloaded Maven release go there the cache key could be trivial.I'll make a change on 10.0 branch to use the Maven Central URL and we'll see if the download failures go away.
headius commentedon Jul 8, 2026
Ugh... the PR to move to using a Maven Central URL immediately had an mvnw download failure: https://github.com/jruby/jruby/actions/runs/28970521797/job/85964762963?pr=9518
headius commentedon Jul 8, 2026
I missed you mentioning this. I'm not sure whether this is cached separately or as part of the overall maven cache; if the latter, then it would be invalidated across PRs, branches, commits potentially (unsure what granularity) which would gain us less than the former model (since it could be cached almost indefinitely so long as the config has not changed).
I'm frustrated that it keeps failing to download, though. Caching would reduce how frequently we need to download it, but perhaps not enough to work around whatever this flakiness is.
chadlwilson commentedon Jul 9, 2026
I'm not sure if it's separate, but it does keep up to 10GB of caches per repo. However, now you've made me think!
I believe the cache is only invalidated/ignored if the set of files (poms, wrapper props) contributing to it change,
not the pom/wrapper content. (edit: this was wrong - it does use the content)This would mean the cache tends to grow over time although you can define your own cache keys. PRs (from other repos) are handled differently to avoid cache poisoning, but can't recall exactly how.headius commentedon Jul 9, 2026
Perhaps we should open an issue to ask about the Maven wrapper caching? I'd like to get some clarification from the setup-java folks on how this works and why we are seeing it fail to download the Maven dist even though we are using Maven caching.
headius commentedon Jul 9, 2026
Aha... it looks like this feature was just added a couple of weeks ago. We should be getting this functionality via
setup-java@v5but clearly we're still seeing the download issues. I'll open a bug.chadlwilson commentedon Jul 10, 2026
Oh right. And yeah, clarified some of my misunderstandings above by re-reading.
We could improve the caching more widely in a few ways I could take a look at - which would probably improve build speeds across the board. Things like
But does seem changing the URL isn't the fix for the dist here.
chadlwilson commentedon Jul 20, 2026
This is mainly fixed upstream in setup-java by splitting the wrapper cache from the regular dependencies, but there are still workflows without caching enabled at all IIRC so will leave this open for now and do a review in a bit.
Enable maven caching for all setup-java uses
headius commentedon Aug 5, 2026
I went through and made sure all active uses of
setup-javaare also usingcache: 'maven'in #9563 so I believe this can be closed.