This broke all our govulncheck CI jobs when running with setup-go and 1.21.x. Our go.mod specify go1.18 and they won't start unless we run go mod tidy before hand.

If this is happening in Github Actions, then I suggest for the time being looking into govulncheck-action. It recently added support for specifying whether the version in go.mod should be used. (it can be fetched at master currently, but we'll release a new version soon)

@zpavlinovic That's basically forcing people to change a their CI files, we have +30 files. This shouldnt be a breaking change.

I don't understand why the Go team is forcing a toolchain. The default value for GOTOOLCHAIN should be "local" or "path", with "auto" go forces you to run go mod tidy if your go.mod files specify a version other than 1.21.

We are trying to find the approach that is most useful for most people. It seems to us that most people are not running Go in a CI, they are running Go from the command line. We've tried to document the new behavior as many places as we could. Sorry for the trouble.

@ianlancetaylor What are all the teams developing applications in Go using to run tests/etc on their CI if not for Go itself?

We also noticed that all the dependabot jobs stopped and are failing because when go mod tidy runs it cant parse go 1.21 as seen here #62278

Also related dependabot/dependabot-core#7895

Personally I expect them to use Go, and I expect them to set GOTOOLCHAIN=local in the environment or in a go.env file, as discussed at https://go.dev/doc/toolchain. I agree that there is a transition cost, but I think we can get through it.

Personally I expect them to use Go, and I expect them to set GOTOOLCHAIN=local in the environment or in a go.env file, as discussed at https://go.dev/doc/toolchain. I agree that there is a transition cost, but I think we can get through it.

Not sure what to say, when even Dependabot doesnt work anymore. I will remove 1.21 from the CI, until a solution is available.