Setup a consistent way to manage go version

[ahrtr]

What would you like to be added?

Currently there are multiple places setting the go versions, for examples,

• go.mod files, including both go and toolchain directives;
• .go-version file;
• environment variable, such as tests: set GOTOOLCHAIN var for report validation #17734

We should set up a consistent way to manage go version. There should be only one source of truth for the go&toolchain version.

One problem is that if a dependency sets a higher go or toolchain version, then when running scripts/fix.sh will automatically update the go & toolchain version in our go.mod files. Refer to https://github.com/etcd-io/etcd/pull/17841/files#r1575344566

References:

• https://go.dev/doc/toolchain
• https://github.com/kubernetes/community/blob/master/contributors/devel/development.md#building-kubernetes-using-a-specific-version-of-go

cc @fuweid @henrybear327 @ivanvc @jmhbnz @MadhavJivrajani @serathius

Why is this needed?

Setup consistent way to manage go version

[MadhavJivrajani]

One problem is that if a dependency sets a higher go or toolchain version, then when running scripts/fix.sh will automatically update the go & toolchain version in our go.mod files.

We are trying to be more careful about this situation in Kubernetes (ref: kubernetes/kubernetes#123744).

One thing we should keep in mind here also is that if dependabot bumps the go directive of the root go.mod and we don't reflect that change in the .go-version file then it could be problematic for reasons similar to kubernetes/kubernetes#123744, if that happens, we are in a situation where:

• We build with a go version that is in .go-version, because the release GH action uses that as source of truth.
• However, if the go directive in go.mod is newer, go will default the values of GODEBUG based on the value of the go directive (see https://go.dev/doc/godebug). This will alter the runtime behaviour because the user might expect behaviour similar to whatever the go directive is, but the actual behaviour is that of .go-version.

In Kubernetes we added a pre-submit check to catch such accidental bumps if they occur: kubernetes/kube-openapi#467

[ahrtr]

In Kubernetes we added a pre-submit check to catch such accidental bumps if they occur: kubernetes/kube-openapi#467

Thanks @MadhavJivrajani

I think we should do similar check for all etcd branches: including release-3.4, release-3.4 and main.

The other potential enhancement is to automatically populate the go versions for the go and toolchain lines in all go.mod (and go.sum) files based on the .go-version file.

[MadhavJivrajani]

I have some ideas on how we can go about doing this. Will create a PR and we can discuss there!

[ahrtr]

Followups:

• Update document: [RFC] Setup a way to consistently manage go versions across scripts and go.mods #17876 (comment)
• Refactor the ./scripts/fix.sh as mentioned in [RFC] Setup a way to consistently manage go versions across scripts and go.mods #17876 (comment)

[ahrtr]

I think we also need to backport the changes to both 3.5 and 3.4

[ahrtr]

We should follow the same rule to manage go version for all repositories under etcd-io. Note we only require users to depend on a minor version supported by golang team, i.e. 1.21, but we don't force users to depend on a patch version, i.e. 1.21.10.