Revert "Update to setup-go@v4 action"

[samuelkarp]

Revert #8365 per issues described in opencontainers/runc#3820 (comment) and actions/setup-go#368

[mikebrow]

LGTM

[kolyshkin]

I see no reason to revert, given that

• you're not testing this on multiple Ubuntu versions
• you're using Go 1.20 which seems to not reuse "wrong" cached data

[samuelkarp]

That's fair, though if there's a known issue related to mixing up cache artifacts I'd want to avoid risking it with our release workflow (which this isn't), and keeping as much of the setup the same between regular CI and release workflow helps reduce the chance of weird errors there too.

[kolyshkin]

That's fair, though if there's a known issue related to mixing up cache artifacts I'd want to avoid risking it with our release workflow (which this isn't), and keeping as much of the setup the same between regular CI and release workflow helps reduce the chance of weird errors there too.

The release workflow uses a different Ubuntu distro, a different golang version, a different way of building binaries, and it does not use 'actions/setup-go` at all. With all that, I am unsure this PR serves the stated purpose.

[thaJeztah]

Yes, perhaps it doesn't affect containerd in the same way as runc, and perhaps a revert is not needed at this point.

I am still interested to understand though "how shared" those caches are (if someone knows). Flakiness on pull requests is "one", but binaries released using potential old (or invalid) cache state is definitely something we should be concerned about (at least have an understanding what's used). Probably also have a look at the Go binaries themselves (e.g., from a recent conversation with someone, it seemed like it may be downloading Go binaries without checksum validation)

TL;DR; we can probably stay at v4 (for now), but perhaps someone with a better understanding of the setup-go-action code should verify what it all does.

[samuelkarp]

Thanks @kolyshkin!

I still think the issue in actions/setup-go#368 is a pretty big footgun that it's better to avoid, even if v4 has better performance.

[kolyshkin]

I am still interested to understand though "how shared" those caches are (if someone knows).

If we're talking about action/setup-go@v4, it seems that the cache is used for all jobs in a repo, and the cache key contains the following elements:

• runner.os (e.g. linux);
• the version of go used;
• the hash of go.mod file.

So, it's the same cache for all jobs for a specific platform. The cache, if exists, is restored when setting up golang, and is saved after the job is done (at the "Post run" step at the very end). I have no idea how this works with parallel jobs.

💡 Hah! I just looked at the ci job runs and found out that since there's no go.mod in the top-level directory (because actions/setup-go is called before actions/checkout, no caching is done! I have checked that this is true for all 9 cases of using actions/setup-go in ci.yml.

Flakiness on pull requests is "one", but binaries released using potential old (or invalid) cache state is definitely something we should be concerned about (at least have an understanding what's used).

From what I see, the release process (in release.yml) is using buildx and a new Docker container, with no caching.

[kolyshkin]

Also, if there's a need to disable actions/setup-go caching, a way to do it is to add cache: false parameter. At least this is explicit (unlike rolling back a version).

[samuelkarp]

Thanks @kolyshkin. Closing in favor of #8487.