alt Hacker NewsThere are some good off-cuts that didn't make the official post, but which might be of interest to HN!
It only gets a brief mention, but the cache-pruning change was an interesting one. Cache accretion happens in the default actions/setup-go too, but dramatically increasing the number of cache-writes for cloudx-io/setup-go made it an actual issue.
As the cache grows, so does the time it takes to load it from GitHub's actions cache... and that grows until it's a significant time-suck in CI. We prune with basic mark-and-sweep.
Digging deeper, the pluggable `GOCACHEPROG` (introduced in Go 1.24) is a really useful tool. Shimming the normal cache logic for measurement, for example. In theory this should also be attractive for remote caching.
Replies
I also had fun substantiating the claim "86% of actions/setup-go test runs are unnecessary." We had a general sense things were faster, and we measured impacts immediately after we made changes, but hard to understand long-run performance vs. a counterfactual.
The trick was to run back over our git history and calculate, for each commit,
1. The test package Go cache keys at that point
2. The GitHub actions/cache keys constructed by actions/setup-go and cloudx-io/setup-go respectively
Once you have these mappings, you can
1. Pick some arbitrary HEAD commit
2. Model which prior GitHub cache blob would be loaded under each action
3. Compare the test package Go cache keys in that loaded blob against those for HEAD to determine which test packages would run vs. skip
Might write this up in greater depth sometime soon.
The way caches are managed in CI is bonkers (at least in GitLab, but GitHub probably does the same). I guess it's built to conveniently work with the simplest of projects. I had to reimplement the mechanism by hand just to get basic things working, like not downloading the entire cache when only a few entries will be used for each build