define how we do Go version upgrades

[protocol]

define how we do Go version upgrades

[mvdan]

Just one nit: make sure editing the Go version in go.mod happens before you re-run all the checks like tidy, fix, gofmt, etc. Tidy will definitely change behavior with the version being declared as 1.17, and it's likely tools like fix will start doing the same in the future too.

[mvdan]

Sounds like a good checklist. Changes to gofmt should be rare, but they do sometimes happen. go fix is similarly not used for major versions these days, but I think it will start being used again soon, as heavier changes are done to the std lib and language.

When you bump the Go version in go.mod, you should also re-run go mod tidy, because the meaning of a tidied module can change with each Go version. For example, 1.17 introduces "lazy module loading", which will add more indirect lines to go.mod, and that's turned on if your installed Go version is 1.17 or later and the Go version in go.mod is 1.17 or later. So bumping the Go version in go.mod to 1.17 but not re-running tidy would leave the module untidied.

It's also possible that go vet would also start failing due to new checks, but nothing we can automate there.

[marten-seemann]

Thanks, I edited the list.

[marten-seemann]

What I would like to do is set a label "go-version-update" on the PR, and only execute these steps if that label is set.

The problem is that we don't get access to the PR metadata because we're triggering our workflow on push to master, since GitHub Actions doesn't have a dedicated "PR merged" event.

[marten-seemann]

I confirmed that the GitHub Event JSON doesn't contain any references to the PR that is being merged, other than the commit message, which consistently is of the form Merge pull request #XX from YY.
We could parse that message to extract XX from that, and then use the GitHub API to look up that Pull Request. Needless to say, this is a lot more hacky than I wish this would be.

[mvdan]

A coming PR is going to implement this. A future PR will document the steps to do every six months in the README.

[galargh]

I think this can be considered documented in code by now. Here's a link to a dedicated workflow which performs Go version upgrades in repositories enrolled in Unified CI - https://github.com/pl-strflt/uci/blob/main/.github/workflows/update-go.yml.