ci: restore Maven cache from master-produced caches in maven-verify#1399
Open
joaodinissf wants to merge 1 commit into
Open
ci: restore Maven cache from master-produced caches in maven-verify#1399joaodinissf wants to merge 1 commit into
joaodinissf wants to merge 1 commit into
Conversation
This was referenced May 31, 2026
joaodinissf
force-pushed
the
ci/maven-verify-cache-restore-keys
branch
from
2ffb917 to
f145e0c
Compare
joaodinissf
force-pushed
the
ci/maven-verify-cache-restore-keys
branch
from
f145e0c to
df9375b
Compare
joaodinissf
changed the title
auto-merge was automatically disabled
June 12, 2026 21:07
Pull request was converted to draft
joaodinissf
force-pushed
the
ci/maven-verify-cache-restore-keys
branch
2 times, most recently
from
0301a05 to
a3330b5
Compare
auto-merge was automatically disabled
July 8, 2026 02:43
Pull request was converted to draft
The maven-verify cache never hit in practice, for three compounding reasons
(verified against the live cache inventory):
- actions/cache only restores on an exact key match, and the key embedded
hashFiles('**/pom.xml') - so any pom-touching PR missed outright.
- GitHub isolates caches per PR scope: the open PRs each held a byte-identical
~700 MB cache under their own refs/pull/N/merge, invisible to one another.
The only shareable scope is master, and verify.yml (a pull_request-only
workflow) never saved there.
- The redundant per-PR saves pushed the repo over its 10 GB cache budget
(10+ GB across 14 caches), so LRU eviction also killed same-PR reuse.
Fix, all in the one cache step: switch to actions/cache/restore (PRs stop
saving - ends the duplicate-cache churn and the eviction pressure) and mirror
the producer exactly. master DOES have a producer - snapshot.yml saves
~/.m2/repository as Linux-maven-publish-* on every push - so maven-verify now
adopts that family's exact path spec and key recipe. The mirroring must be
literal: GitHub hashes the path spec into the cache *version* and only serves
a cache whose key AND version both match, so ~/.m2/repository vs
/home/runner/.m2/repository alone makes the producer's caches silently
unmatchable (the repo's cache inventory showed the two path spellings under
distinct version hashes). A PR that touches no pom/target files exact-hits
master's newest cache; any other PR prefix-restores it via restore-keys.
The cache-bust lever is renaming the maven-publish family in snapshot.yml
and here together.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
joaodinissf
force-pushed
the
ci/maven-verify-cache-restore-keys
branch
from
a3330b5 to
93d4cce
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
maven-verifycache never hits in practice. Three compounding causes, verified against the live cache inventory:hashFiles('**/pom.xml'), so every pom-touching PR (each dependabot bump) missed outright — e.g. run 27416121979:Cache not found for input keys: Linux-maven-0-3ecae…followed by a full cold download.refs/pull/N/mergescope, invisible to one another. Only master-scoped caches are shareable, andverify.yml(pull_request-only) never saves there. Meanwhilesnapshot.ymldoes produce a master-scopedLinux-maven-publish-*cache on every push.The fix stays within the one cache step:
actions/cache/restore(restore-only): PRs stop saving — ends the duplicate-cache churn and the eviction pressure (steady state ≈ a few master caches).snapshot.yml's literal path spec (~/.m2/repository) and key recipe (Linux-maven-publish-+hashFiles('**/pom.xml', '**/*.target')). This is load-bearing: GitHub serves a cache only when key and version match, and the version is a hash of the literal path spec —/home/runner/.m2/repositoryvs~/.m2/repositoryalone puts producer and consumer in disjoint version families (visible in the repo's cache inventory as two distinct version hashes for the same directory). A PR that touches no pom/target files exact-hits master's newest cache; any other PR prefix-restores it viarestore-keys.maven-publishfamily insnapshot.ymland here together.Proven live on this PR — A/B, one commit apart, same three publish caches present on master:
0301a0538(run 28912306532)Cache not found for input keys: Linux-maven-0-813d39e…, Linux-maven-0-, Linux-maven-publish-→ cold downloada3330b5fe(run 28913047642)Cache restored from key: Linux-maven-publish-a45921afc7…(~1096 MB, exact hit on master's newest cache)Post-run, the cache API shows zero caches under
refs/pull/1399/merge— PRs no longer save.🤖 Generated with Claude Code