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
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 embeds
hashFiles('**/pom.xml') — so any pom-touching PR missed outright.
- GitHub isolates caches per PR scope: the eight open PRs each held a
byte-identical 704 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.
- master DOES have a cache producer — snapshot.yml saves ~/.m2/repository
as Linux-maven-publish-* on every push — but verify's restore prefix
(Linux-maven-0-) could never match that family. snapshot.yml's own
restore-keys already reach down into Linux-maven-0-; the sharing was
one-directional by accident.
- The redundant per-PR saves pushed the repo over its 10 GB cache budget
(10.35 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), add
restore-keys with prefix fallback, and include Linux-maven-publish- so every
PR warm-starts from the snapshot build's superset cache, refreshed on each
merge to master. The maven-0 epoch remains the manual bust lever.
Mechanism verified in a fork experiment (#26): a pom-touching
second run logged 'Cache restored from key: Linux-maven-0-…' and round-
tripped the cached content.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
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 — and its own restore-keys already reach down intoLinux-maven-0-, so the sharing was one-directional by accident.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 ≈ two master caches, ~1.5 GB).restore-keysprefix fallback, includingLinux-maven-publish-: every PR warm-starts from the snapshot build's~/.m2(a superset of what verify needs), refreshed on each merge to master. Themaven-0epoch remains the manual cache-bust lever, and the explicit two-prefix list keeps a future epoch bump effective.Mechanism verified end-to-end in a fork experiment (joaodinissf#26): after a pom touch, the second run logged
Cache restored from key: Linux-maven-0-…and round-tripped the cached content from the first run.🤖 Generated with Claude Code