2 Commits
Author SHA1 Message Date
Matthew HughesandGitHub 1d76b952eb Improve toolchain handling (#460)
* 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: if the `toolchain` version in `go.mod` was
  greated than the `go` version, the version from the `go` directive
  would be installed, then Go would detect the `toolchain` version and
  additionally install that
* 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)

[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` 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_.

Link: https://go.dev/doc/toolchain#config [1]
Issue: https://github.com/actions/setup-go/issues/457

* squash! Configure environment to avoid toolchain installs

Only modify env if `GOTOOLCHAIN` is not set

* squash! Prefer installing version from `toolchain` directive

Avoid installing from `toolchain` if `GOTOOLCHAIN` is `local`, also
better regex for matching toolchain directive
2025-08-28 22:21:56 -05:00
Matthew HughesandGitHub e75c3e80bc Bump form-data to bring in fix for critical vulnerability (#618)
The vulnerability:

    $ npm audit --audit-level=high
    # npm audit report

    form-data  >=4.0.0 <4.0.4 || <2.5.4
    Severity: critical
    form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
    form-data uses unsafe random function in form-data for choosing boundary - https://github.com/advisories/GHSA-fjxv-7rqg-78g4
    fix available via `npm audit fix`
    node_modules/@azure/core-http/node_modules/form-data
    node_modules/@types/node-fetch/node_modules/form-data
    node_modules/form-data

    1 critical severity vulnerability

    To address all issues, run:
      npm audit fix

This change is the result of from running `npm audit fix` and then
using[1] to update licenses via `licensed cache`.

It doesn't look like `dependabot` previously raised any PRs for this
dependency, so this bumps it from `4.0.0` to `4.0.4`, see the
changelog[2] for details.

Link: https://github.com/licensee/licensed [1]
Link: https://github.com/form-data/form-data/blob/v4.0.4/CHANGELOG.md [2]
2025-08-13 12:02:46 -05:00