Force go to always use the local toolchain (i.e. the one the one that
shipped with the go command being run) via setting the GOTOOLCHAIN
environment variable to local[1]:
When GOTOOLCHAIN is set to local, the go command always runs the
bundled Go toolchain.
This is how things are setup in the official Docker images (e.g.[2], see
also the discussion around that change[3]). The motivation behind this
is to:
Reduce duplicate work, the action will install a version of Go, a
toolchain will be detected, the toolchain will be detected and then
another version of Go installed
Avoid Unexpected behaviour: if you specify this action runs with some Go
version (e.g. 1.21.0) but your go.mod contains a toolchain or go
directive for a newer version (e.g. 1.22.0) then, without any other
configuration/environment setup, any go commands will be run using go
1.22.0
This will be a breaking change for some workflows. Given a go.mod
like:
module proj
go 1.22.0
Then running any go command, e.g. go mod tidy, in an environment
where only go versions before 1.22.0 were installed would previously
trigger a toolchain download of Go 1.22.0 and that version being used
to execute the command. With this change the above would error out with
something like:
go: go.mod requires go >= 1.22.0 (running go 1.21.7;
GOTOOLCHAIN=local)
Prefer installing version from toolchain directive
Prefer this over the version from the go directive. Per the docs[1]
The toolchain line declares a suggested toolchain to use with the
module or workspace
It seems reasonable to use this, since running this action in a
directory containing a go.mod (or go.work) suggests the user is
wishing to work with the module or workspace.
Check list:
[ ] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.
Configure environment to avoid toolchain installs
Force
go
to always use the local toolchain (i.e. the one the one that shipped with the go command being run) via setting theGOTOOLCHAIN
environment variable tolocal
[1]:This is how things are setup in the official Docker images (e.g.[2], see also the discussion around that change[3]). The motivation behind this is to:
1.21.0
) but your go.mod contains atoolchain
orgo
directive for a newer version (e.g.1.22.0
) then, without any other configuration/environment setup, any go commands will be run using go1.22.0
This will be a breaking change for some workflows. Given a
go.mod
like:Then running any
go
command, e.g.go mod tidy
, in an environment where only go versions before1.22.0
were installed would previously trigger a toolchain download of Go1.22.0
and that version being used to execute the command. With this change the above would error out with something like:[1] https://go.dev/doc/toolchain#select [2] https://github.com/docker-library/golang/blob/dae3405a325073e8ad7c8c378ebdf2540d8565c4/Dockerfile-linux.template#L163 [3] https://github.com/docker-library/golang/issues/472
Prefer installing version from
toolchain
directivePrefer this over the version from the
go
directive. Per the docs[1]It seems reasonable to use this, since running this action in a directory containing a
go.mod
(orgo.work
) suggests the user is wishing to work with the module or workspace.Check list: