Update default value for GOTOOLCHAIN env variable

[gaby]

With the release of go1.21 the behavior for running changed, by default go will now use GOTOOLCHAIN=auto which will fail to run your code unless you do go mod tidy if the go version specified in go.mod is older than the one in setup-go.

One fix for this is to set GOTOOLCHAIN=local, so that go doesn't try to force update your toolchain. Add support for specifying the GOTOOLCHAIN, or set it to GOTOOLCHAIN=local by default.

Docs:

• https://tip.golang.org/doc/go1.21
• https://tip.golang.org/doc/toolchain

[gaby]

Related

• extended forwards compatibility for Go golang/go#57001
• x/vuln/cmd/govulncheck: check against toolchain/go directive version golang/go#62050

[dsame]

Hello @gaby , thank you for your input. We start to investigate the problem.

[gaby]

@dsame Thanks! I don't expect the Go team to change this default value.

[gaby]

Also related: golang/go#62409

[dsame]

Hello @gaby,

Despite the specifying GOTOOLCHAIN is as easy as any other environment variables
https://docs.github.com/en/actions/learn-github-actions/variables#defining-environment-variables-for-a-single-workflow

i still do not understand the problem well, namely why this can be happen:

will fail to run your code unless you do go mod tidy if the go version specified in go.mod is older than the one in setup-go.

according the documentation of Go the newer toolchain will be used in this case. I.e. go.mod version will be ignored see " the new toolchain would be used automatically"

Can you please provide the sample where the build filed because of setup-go version is newer than the version set in go.mod?

And does it help to set GOTOOLCHAIN to the desired value for the workflow manually? So far my understanding is the default value "auto" works best in the most cases.

[gaby]

@dsame Yes, it happens here https://github.com/gofiber/contrib/actions/runs/6047961443/job/16412414494

The CI file is located here: https://github.com/gofiber/contrib/blob/main/.github/workflows/govulncheck.yml

The go.mod file for the failure is here: https://github.com/gofiber/contrib/blob/main/paseto/go.mod

[gaby]

@dsame Closing this, the issue was caused by a dependency requiring go 1.21

The explanation can be found here golang/go#62409 (comment)

Thanks for your help!