Summary
The repo blew past GitHub's 10 GB Actions cache cap (10.53 GB across 19 entries) after the go-deps group bump in #438. Past the cap GitHub LRU-evicts, so warm entries vanish mid-run and builds silently get slower and less predictable.
Root cause
.github/actions/setup-env/action.yml caches the Go module cache and the Go build cache together, under a key partitioned per compile flavor:
path: |
~/go/pkg/mod # pure function of go.sum — identical for every flavor
~/.cache/go-build # genuinely flavor-specific
key: gobuild-v2-${{ runner.os }}-go${{ inputs.go-cache-suffix }}-${{ hashFiles('**/go.sum') }}~/go/pkg/mod measures 1.6 GB for the current go.sum and is byte-identical across all five suffixes (-lint, -unit, -integration, -e2e-cov, -cov). So it was stored five times — roughly 5 GB per go.sum generation.
The observed inventory, mid-incident:
1210MB gobuild-v2-Linux-go-lint-136f5059…
1068MB gobuild-v2-Linux-go-unit-136f5059…
1067MB gobuild-v2-Linux-go-integration-136f5059…
1058MB gobuild-v2-Linux-go-unit-1a18a4a1… <- previous generation
1033MB gobuild-v2-Linux-go-e2e-cov-136f5059…
929MB gobuild-v2-Linux-go-cov-1a18a4a1… <- previous generation
928MB gobuild-v2-Linux-go-cov-136f5059…
Two live generations is the normal steady state — a go.sum bump mints a fresh set while the previous is still warm — so ~10 GB was the expected footprint, not an anomaly. #438 changed 24 modules and tipped it over.
The action's own header comment already noted the duplication ("Cross-suffix restore-keys still share the (identical) module cache on a cold start") without drawing the sizing conclusion.
Fix
Split the one cache into two:
gomod-v1-<os>-<go.sum hash> → ~/go/pkg/mod, unsuffixed, shared by every Go jobgobuild-v3-<os>-go<suffix>-<go.sum hash> → ~/.cache/go-build only, still per flavor
Estimated ~5 GB → ~2 GB per generation, so two generations fit with headroom.
Notes
- GitHub's LRU eviction has since reclaimed the stale generation on its own (now 7.19 GB / 13 entries), so this is not currently breaking builds — but it recurs on the next dependency bump.
- The
v3 bump on the build key is required: saves only fire on an exact-key miss, so without it the old v2 entry (still carrying the module cache) would exact-hit forever and the new, smaller content would never be saved.
Summary
The repo blew past GitHub's 10 GB Actions cache cap (10.53 GB across 19 entries) after the go-deps group bump in #438. Past the cap GitHub LRU-evicts, so warm entries vanish mid-run and builds silently get slower and less predictable.
Root cause
.github/actions/setup-env/action.ymlcaches the Go module cache and the Go build cache together, under a key partitioned per compile flavor:~/go/pkg/modmeasures 1.6 GB for the currentgo.sumand is byte-identical across all five suffixes (-lint,-unit,-integration,-e2e-cov,-cov). So it was stored five times — roughly 5 GB pergo.sumgeneration.The observed inventory, mid-incident:
Two live generations is the normal steady state — a
go.sumbump mints a fresh set while the previous is still warm — so ~10 GB was the expected footprint, not an anomaly. #438 changed 24 modules and tipped it over.The action's own header comment already noted the duplication ("Cross-suffix restore-keys still share the (identical) module cache on a cold start") without drawing the sizing conclusion.
Fix
Split the one cache into two:
gomod-v1-<os>-<go.sum hash>→~/go/pkg/mod, unsuffixed, shared by every Go jobgobuild-v3-<os>-go<suffix>-<go.sum hash>→~/.cache/go-buildonly, still per flavorEstimated ~5 GB → ~2 GB per generation, so two generations fit with headroom.
Notes
v3bump on the build key is required: saves only fire on an exact-key miss, so without it the old v2 entry (still carrying the module cache) would exact-hit forever and the new, smaller content would never be saved.