slachiewicz commented on code in PR #339:
URL:
https://github.com/apache/maven-gh-actions-shared/pull/339#discussion_r4247291834
##########
.github/workflows/maven-verify.yml:
##########
@@ -314,6 +314,9 @@ jobs:
with:
java-version: ${{ inputs.ff-jdk-toolchain }}
distribution: ${{ inputs.ff-jdk-distribution }}
+ cache-jdk: true
+ # only the default branch saves caches; other branches and pull
requests restore them
+ cache-read-only: ${{ github.ref_name !=
github.event.repository.default_branch }}
Review Comment:
Feature branches still restore caches, just not their own: a run can restore
caches saved on its branch or on the default branch ([cache access
rules](https://docs.github.com/en/actions/reference/workflows-and-actions/dependency-caching#restrictions-for-accessing-a-cache)),
so a branch whose poms match master's gets master's `~/.m2` and JDK caches on
every run and re-run. You're right about a long-lived branch that changes its
poms: setup-java restores only on an exact pom-hash key
([cache.ts](https://github.com/actions/setup-java/blob/de7274f081f381c8f8158605e0321c36c376e2e6/src/cache.ts)),
so it would download its dependencies on every run. For that case,
`cache-save-branches` (a JSON array, default `[]`) lets a project list branches
that keep saving their own caches.
What it saves: every branch and PR stored its own ~170 MB per OS that no
other ref can read. Repositories hit the 10 GB limit and evicted master's
entries, which slowed every build. Across 27 mojohaus repos, 42.6 GB were
caches of deleted branches and closed PRs.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
