Matthew Hughes 763ffebcce 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 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` * TODO: link image 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) [1] https://go.dev/doc/toolchain#select [2] dae3405a32/Dockerfile-linux.template (L163) [3] https://github.com/docker-library/golang/issues/472		2024-10-14 19:46:15 +01:00
..
index.js	Configure environment to avoid toolchain installs	2024-10-14 19:46:15 +01:00