2 Commits

This Branch

This Branch

All Branches

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