Maybe we should also add 'stable' (and 'oldstable') to CI, too (perhaps only in release-* branches, not in main).

Otherwise we may end up running tests with e.g. Go 1.23 but building release binaries using Go 1.25. I remember @thaJeztah had his reasons to not do that, but I don't remember what was it exactly.

Things I'm on the fence on;

• With this change, the version in the Dockerfile (and elsewhere) is not updated; for most of our dependencies, we explicitly have the version used captured in source-control (i.e., I could open the tag, and see what was used); this also makes updating the go version an explicit action, while (through the --build-tag or otherwise), it would still allow packagers to override the version.
• IIUC, this change would not change CI to be using these versions, which means that a release would use a different version of Go than was tested; potentially hiding subtle changes in Go that we know are sometimes causing regressions.

Would we have some check in CI that the version of Go used is matching the current patch release of the minor version used in the branch, and that minor version to not be an EOL version at time of release? (Which may be "oldstable" for specific branches)?

Well, if we decide to just use stable/oldstable in CI then we don't really need to pin a Go version in Dockerfile and we can just use stable for everything. From memory we originally pinned Go versions to avoid having to fix new Go version errors in CI in old branches, which is what we will have to go back to if we end up auto-updating in CI.

Maybe we need to take a step back and ask what we actually want to achieve:

1. How important is it that our releases are built with the latest Go compiler? (Given that we do not rebuild binaries for old releases and thus all releases will eventually be built with "old compilers". This even applies for Go stdlib security vulnerabilities, which are a more pressing issue than recently-EOL'd compiler versions.)
2. How much pain do we expect to see from always testing with stable/oldstable? Are we okay with just testing with stable/oldstable and then dealing with the fallout when we run into it?
3. What do the users of our compiled binaries actually expect from us? I mainly kept including binaries in our releases because that was what @crosbymichael did back in the day when I took over release management from him, and we obviously have users that want this (@akhilerm being one, I guess). I have used our binaries a few times when SSH'd into a machine without a Go compiler, and in that case I didn't really care about which Go compiler version it was built with...

My view is that using GO_VERSION=1 is fine because cases where Go breaks runc are usually notable and making GO_VERSION configurable provides an easy way of working around it when doing releases if/when we run into this again -- in the absence of such a case then using the latest version should be the easy path. Given how rare it is, I think having an oldstable or even just stable CI run would be fine, though it does force us to fix issues as soon as they come up...

In our use case, we are not directly consuming the binaries from runc releases. But we build runc internally with the same go version that was used to compile the release binaries.

Closing in favour of #4997.