Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Improve toolchain handling #460

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Improve toolchain handling #460

wants to merge 2 commits into from

Commits on Oct 14, 2024

  1. 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] https://github.com/docker-library/golang/blob/dae3405a325073e8ad7c8c378ebdf2540d8565c4/Dockerfile-linux.template#L163
[3] docker-library/golang#472
    @matthewhughes934
    matthewhughes934 committed Oct 14, 2024
    Configuration menu
    Copy the full SHA
    763ffeb View commit details
    Browse the repository at this point in the history

  2. 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_.

See (TODO link issue)
    @matthewhughes934
    matthewhughes934 committed Oct 14, 2024
    Configuration menu
    Copy the full SHA
    145e58d View commit details
    Browse the repository at this point in the history