Repository navigation
Only save Go caches from trunk - #14840
Merged
Merged
Conversation
Pull requests restore the per-job Go caches but no longer save them, falling back to the latest trunk cache when go.mod changes. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 4a5f4c22-1eba-41b2-a77e-3d29b257ace9
williammartin
requested review from
BagToad
and
a balanced review from Copilot
October 27, 2026 13:58
2 of 6 tasks
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are reported for the change restricting Go cache saves to trunk.
No open issues 🎉
What changed in this PR
This PR limits Go cache saves to trunk, reducing cache storage consumed by pull requests while preserving the separate job caches introduced in #14837.
Changes:
- Centralizes cache key construction without changing the existing key format.
- Restricts cache saving to
trunk, using exact-key matching without fallback. - Makes other refs restore-only, with a compatible prefix fallback when
go.modchanges.
| File | Description |
|---|---|
.github/actions/setup-go/action.yml |
Separates trunk caching from restore-only behavior and computes shared cache keys. |
Review effort: Balanced
babakks
approved these changes
Oct 27, 2026
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
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.
Relates to #14837
Description
#14837 gave the
buildandintegration-testsjobs ingo.ymltheir own Go caches, keyed on the job, OS, runner image, Go version andgo.mod. A race cache is about 520 MB and a non-race cache about 300 MB, so every run that misses saves about 2.5 GB across the three OSes.Pull requests that change
go.mod, which Dependabot opens often, each miss and save their own copy. Those caches can only be restored by that pull request, so they take up the repository's cache storage and push out thetrunkcaches everything else relies on.This PR changes
.github/actions/setup-goso that onlytrunksaves caches. Pull requests restore them withactions/cache/restore, and fall back to the latesttrunkcache for the same job, OS and Go version whengo.modhas changed.How did you test this change?
Not tested. The restore path runs in this PR's own CI, but the save path only runs on
trunk, so I can't exercise it before merging.Key points
go.modrestores an oldertrunkcache on every run, rather than building cold once and then reusing its own cache. I think most packages still match, so this costs little, but I haven't measured it.trunksaves on an exact key only, with no fallback to an older cache. Building on a restored older cache would keep adding stale packages to it.buildjob also buildsghwithout-raceafter the tests, so those packages end up in the race cache too. I suspect they add only about 30 MB, so I didn't split them out.Notes for reviewers
The whole change is in
.github/actions/setup-go/action.yml. The key format is unchanged from #14837, so existingtrunkcaches still match.Authorship and follow-up
Who wrote this:
Who answers review comments: