mirror of
https://github.com/mattermost/mattermost.git
synced 2026-10-13 17:37:59 +08:00
Jesse Hallam
cd9bcb005e
* chore: extract install-<tool> Makefile targets
Pull each `go install` of a build tool into its own `install-<tool>`
target so the installs are declared once and reused as prerequisites,
and add `install-ci-tools` plus a `go-cache` target that pre-warms the
Go module and build caches.
Also collapse the duplicate `vet-api` target declarations into one.
* chore(ci): add restore-go-cache composite action
* chore(ci): mount warmed Go cache into run-in-buildenv
* chore(ci): add daily Go module/build cache warm workflow
* chore(ci): restore warmed Go cache read-only across server CI jobs
* Simplify Go cache key to glob-match all go.mod and go.sum files
* make GOBIN explicit
* Pass Go cache paths as step outputs, not GITHUB_ENV
restore-go-cache wrote GOMODCACHE/GOCACHE/GOBIN to GITHUB_ENV so later
steps would pick them up. zizmor flags any GITHUB_ENV write as a possible
code-execution vector, since an attacker-controlled value there can set
LD_PRELOAD or NODE_OPTIONS for every subsequent step.
Nothing untrusted reaches these particular values, but the write is also
unnecessary: expose them as action outputs and map them into the one step
that actually needs them, matching what 8f6d17d875 did for the buildenv
actions.
Only server-test-template's shard split consumes them outside the action.
Everything else either runs in the buildenv container, which gets the
container paths via explicit -e, or reads RUNNER_TEMP directly. That step
runs `go work` and shard-split.js's `go test -list` on the host, so it
takes GOMODCACHE and GOCACHE via env; GOBIN is omitted because the host
never invokes the tools in server/bin.
Also drops the `${{ github.workspace }}` interpolation in favour of the
runner's GITHUB_WORKSPACE, so no expression is expanded into the script.
zizmor now reports no findings for the action, with no ignore comment or
config entry needed.
* Note that server/bin is only a warm start
The cache key covers the Go version and go.mod/go.sum, so it doesn't
invalidate on a tools/mattermost-govet source edit or a Makefile version
pin bump. That reads like a staleness bug until you notice every consumer
re-runs its install-<tool> prerequisite, and `go install` rebuilds on
content, so a stale binary is overwritten before anything uses it.
Say so where the key is described, since it came up in review.