Better GitHub CI caching strategy for golang

[dereknola]

Proposed Changes

Builds off of #9479 (will be rebased when that merges)

Use a custom caching strategy for GitHub Action setup-go, which restricts:

• Only master branch can SAVE caches
• PRs can only RESTORE (ie read) caches

Types of Changes

GitHub CI

Verification

For now, this PR should not open any new caches

Linked Issues

#9494

User-Facing Change

Further Comments

[manuelbuil]

Probably stupid question: what is the benefit of doing this?

[dereknola]

If you look at our Actions caches https://github.com/k3s-io/k3s/actions/caches, we keep going over our 10GB limit with a bunch of setup-go-Linux-ubuntu22-go-1.21.7-bda3a8cce4ad2d34dfb706b901c4ce11eab6d77c2d08dd8f0eae8694a7a27733 caches. Alot of these are from PRs, whose caches are ONLY valid for the PR that opened them for security reasons (cache poisoning prevention).

[dereknola]

The idea is to only allow master branch to Save a valid cache entry, because that cache is usable by all PRs, as along as the checksum is the same (ie no changes to go.mod).

[manuelbuil]

Thanks Derek

[manuelbuil]

I understand now, thanks for the explanation. I have one last question: how long is a cache saved? I'm worried about the case where I open a PR to master but I don't merge because we are on code freeze and then after some days, I create the backports. Could it be that the cache does not exist anymore? In that case, what would happen? It seems we fall back to the restore-key cache which could be built with other go version or go.sum, right? Thanks in advance for this clarification!

[manuelbuil]

Thanks Derek

[dereknola]

I understand now, thanks for the explanation. I have one last question: how long is a cache saved? I'm worried about the case where I open a PR to master but I don't merge because we are on code freeze and then after some days, I create the backports. Could it be that the cache does not exist anymore? In that case, what would happen? It seems we fall back to the restore-key cache which could be built with other go version or go.sum, right? Thanks in advance for this clarification!

Caches that are access at least once a week are saved forever. This assumes you stay under the 10GB limit of course. See Eviction policy. With this change, we will not be caching release-XX branch golang dependencies, so any backports will not utilize the cache. If we find the we can comfortably stay under the 10GB cache limit with this change, we can expand cache saving to the older release branches. Right now everything is getting thrashed and almost none of the GH Action runs are getting cache hits, so being more conservative is the best option.

[manuelbuil]

I understand now, thanks for the explanation. I have one last question: how long is a cache saved? I'm worried about the case where I open a PR to master but I don't merge because we are on code freeze and then after some days, I create the backports. Could it be that the cache does not exist anymore? In that case, what would happen? It seems we fall back to the restore-key cache which could be built with other go version or go.sum, right? Thanks in advance for this clarification!

Caches that are access at least once a week are saved forever. This assumes you stay under the 10GB limit of course. See Eviction policy. With this change, we will not be caching release-XX branch golang dependencies, so any backports will not utilize the cache. If we find the we can comfortably stay under the 10GB cache limit with this change, we can expand cache saving to the older release branches. Right now everything is getting thrashed and almost none of the GH Action runs are getting cache hits, so being more conservative is the best option.

Thanks again for the explanation. As it restores the cache when ${{ github.ref != 'refs/heads/master' }}, I thought backports would consume the cache created by the "master" PR