x/build: catch problems in x/ repos gated by module go directive version sooner

[dmitshur]

Issue #67783 is an example of a test failure that happened only at tip (future Go 1.23 to be) and when the go directive in x/net is increased to Go language version 1.23. Bumping x/net go directive to 1.23 will not happen on its own soon since Go 1.22 and 1.21 are still supported now, but it would be good to have at least one builder that could catch such problems sooner anyway. This is a tracking issue for that.

Edit: Discussion here shows another case where having this implemented would help, by letting vet changes be rolled out more gradually without delay in signal.

CC @golang/release.

[findleyr]

This is a great idea. I suspect x/tools will pick up some problems when its go.mod directive is updated.

[dmitshur]

A sketch of how this can be implemented:

• add an input property to golangbuild, something like upgrade_go_directive
  • when set, builders run go get go@{target go directive} in each module before their usual go test ./...
• add a builder runmod that uses the new property, something like "tiplang", and have one linux/amd64 builder for each golang.org/x repository at tip (main Go repo doesn't need it)

Using x/build as an example, it would have a new post-submit builder named:

x_build-gotip-linux-amd64-tiplang

And the top-level module test sequence would have this one extra command:

 [...] # discover modules to test, download module dependencies in advance, etc.
+go get [email protected]
 go test ./...

I think we can target doing this this at tip, one builder per x/ repo, and afterwards can consider if there's a benefit to doing it for release branches and/or more than just linux/amd64. We'll also need to find a good place where the 1.24 value is determined (config vs golangbuild), aiming to make it easier to maintain the value over time. This can be a starting point.