Every workflow pins Node 20-based actions that GitHub is force-migrating to Node 24

[FrameAutomata]

Surfaced as a run annotation while adding the frontend lint gate (#315):

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4, actions/setup-node@v4

That run only uses two actions. The problem is repo-wide: 12 of the 16 distinct actions in .github/workflows/ declare runs.using: node20, and every one of the 16 workflow files pins at least one.

Inventory

Verified by reading action.yml at each pinned ref; "latest" from each repo's latest release.

Action	Pinned	runs.using	Latest	Uses / files
actions/checkout	v4	node20	v7.0.1	25 / 16
actions/setup-go	v5	node20	v7.0.0	15 / 12
actions/upload-artifact	v4	node20	v7.0.1	10 / 6
actions/download-artifact	v4	node20	v8.0.1	5 / 3
docker/build-push-action	v5	node20	v7.3.0	5 / 1
actions/setup-node	v4	node20	v7.0.0	4 / 4
actions/cache	v4	node20	v6.1.0	4 / 2
cloudflare/wrangler-action	v3	node20	v4.0.0	3 / 3
docker/setup-qemu-action	v3	node20	v4.2.0	1 / 1
docker/setup-buildx-action	v3	node20	v4.3.0	1 / 1
docker/login-action	v3	node20	v4.6.0	1 / 1
azure/setup-helm	v4	node20	v5.0.1	1 / 1

Already fine, no action needed: golangci/golangci-lint-action@v9 (node24), Swatinem/rust-cache@v2 (node24), sigstore/cosign-installer@v3 and anthropics/claude-code-action@v1 (both composite).

frontend.yml, incoming via #315, adds two more @v4 pins (checkout, setup-node) — worth bumping in the same pass rather than landing it already stale.

Why it matters

Today it is only an annotation: the runner silently executes the node20 shim on Node 24. But the forcing is the last step before removal, and the failure mode when it lands is that every workflow breaks at once, including release-traceway.yml, release-cli.yml, release-helm.yml, release-docs.yml and release-website.yml. Losing the ability to cut a release is a bad way to discover this.

Not a sweep — these are multi-major jumps

sed -i 's/@v4/@v7/' is the wrong move; several of these skip 2-3 majors and have real behaviour changes.

Suggested grouping, riskiest last:

1. Low risk, high coverage — checkout v4→v7, setup-go v5→v7, setup-node v4→v7. Setup/checkout actions, no artifact or registry semantics. Covers 44 of the 68 pins.
2. Needs reading the changelogs — upload-artifact v4→v7 and download-artifact v4→v8. Note the majors are already mismatched (v7 vs v8) and the artifact actions changed immutability/naming semantics across v4+. The six benchmark workflows pass artifacts between jobs, so a mistake here silently breaks result collection rather than failing loudly.
3. Publish path, verify before merging — the four docker/* bumps plus cloudflare/wrangler-action v3→v4 and azure/setup-helm v4→v5. All sit on release workflows, so they cannot be validated by a PR label; they want a workflow_dispatch dry run.
4. actions/cache v4→v6 — cache key/restore behaviour changed; worst case is a silent cache miss, which shows up as slower CI rather than a failure.

Groups 1 and 2 are label-validatable on a PR (backend.yml, cli*.yml, frontend.yml and the benchmarks all run on the ci label). Group 3 is the one that needs a maintainer to dispatch manually.

Note

Unrelated to the Go toolchain bump in #307 and the engines.node change in f95424cc — both of those are language runtime versions. This is the Node version the action wrapper itself executes on, and would still fire regardless of what Go or Node the jobs install.

[FrameAutomata]

Split into two PRs along the line the issue draws, since the second half can't be validated by a label:

• ci: move every first-party action off the Node 20 runtime #328 — the 63 actions/* pins (groups 1, 2 and 4). checkout v4→v7, setup-go v5→v7, upload-artifact v4→v7, download-artifact v4→v8, setup-node v4→v7, cache v4→v6. Validatable with the ci label.
• ci: move the release-path actions off the Node 20 runtime #329 — the six third-party actions on the release workflows (group 3), stacked on ci: move every first-party action off the Node 20 runtime #328. Needs a workflow_dispatch dry run; the PR body suggests an order.

After both, every pin in .github/workflows is node24 or composite.

Three notes on things that turned out to differ from the issue's expectations:

setup-go v6 is the one that touches this repo's semantics. It installs the toolchain directive's version instead of the go line's and sets GOTOOLCHAIN=local. Net effect here is nil — both modules pin toolchain go1.26.6, so the same compiler runs, just without the download. The one job that installs an older Go (benchmark-hardware.yml, go-version: '1.25') only builds benchmarks/loadgen, which declares go 1.25. backend-vulncheck.yml documented the v5 mechanism in a comment, so that comment is rewritten.

actions/cache v4→v6 is safer than group 4 assumed. The release notes are Node 24 + ESM only; no key or restore-behaviour change, so no silent cache miss to worry about.

wrangler-action v4 is the real risk in group 3, and it isn't the runtime. Its default Wrangler CLI moves from 3 to 4, and neither website/package.json nor docs/package.json depends on wrangler — so the action's default is literally what deploys tracewayapp.com. #329 pins wranglerVersion: "3" at all three call sites so the runtime bump doesn't smuggle a CLI major bump onto a production deploy path that no PR can test. Wrangler 4 is worth doing on its own.

Two smaller things:

• ci: test the frontend on every labelled PR #315's frontend.yml already pins @v7 (commit 20bac031), so nothing to do there.
• docs/pages/client/js-sdk/sourcemap-upload.mdx ships a copy-paste recipe with checkout@v4 / setup-node@v4; bumped in ci: move every first-party action off the Node 20 runtime #328. website/content/blog/auto-fix-loop.mdx also pins upload-artifact@v4 but it's a published dated post, so left alone.

[dusanstanojeviccs]

Real issue, should be addressed