ci: move the release-path actions off the Node 20 runtime

[FrameAutomata]

Part 2 of #326, now targeting main directly (was stacked on #328; per review, PRs should be independently mergeable). #328 does the 63 actions/* pins; this does the six third-party ones. The two touch four files in common but never the same lines, so they merge in either order.

These are all third-party, all on release workflows. After this and #328, every pin in .github/workflows is node24 or composite.

Action		Workflow
docker/build-push-action	v5 → v7	release-traceway (5 uses)
docker/setup-qemu-action	v3 → v4	release-traceway
docker/setup-buildx-action	v3 → v4	release-traceway
docker/login-action	v3 → v4	release-traceway
cloudflare/wrangler-action	v3 → v4	release-website, -docs, -helm
azure/setup-helm	v4 → v5	release-helm

⚠️ There is no dry run on this path

The earlier version of this description told reviewers to validate with a workflow_dispatch run, "cheapest first: release-helm.yml, it only publishes a chart index." That advice was wrong and I am retracting it. Dispatching these workflows deploys for real:

• release-docs.yml / release-website.yml run wrangler-action with command: deploy and secrets.CLOUDFLARE_API_TOKEN — dispatching either publishes to production Cloudflare from whatever ref you pick.
• release-helm.yml runs pages deploy deploy --project-name traceway-charts, overwriting the live chart index. Lower stakes than the marketing site, but a broken index breaks helm repo update for every existing install.
• release-traceway.yml pushes real images.

So this is validated by reading release notes against how the actions are actually called, below — not by running them. The first real exercise is the next release, which is why the one behaviour-changing default is pinned rather than taken.

wrangler-action v4 changes the Wrangler CLI major — pinned here

v4's headline change is that its default Wrangler CLI moves from 3 to 4. Neither website/package.json nor docs/package.json depends on wrangler, so there is no project-pinned CLI for the action to pick up — its default is literally what deploys tracewayapp.com and the docs.

Taking v4 unpinned would smuggle a CLI major bump into a change whose entire purpose is a runtime bump, on a production deploy path with no pre-merge test. So all three call sites pin:

wranglerVersion: "3"

Same CLI as today, new runtime. Wrangler 4 is tracked separately as #331, referenced from all three sites so the deferral survives #326 closing. The route to validating that one is to make wrangler a devDependency of website/ and docs/, which moves the CLI into the lockfile where npm ci exercises it under the ci label.

Why the other five are inert here

build-push-action v6 turned on build summaries (default on, additive — a summary panel plus an exported build record per build). v7 removed the deprecated DOCKER_BUILD_NO_SUMMARY and DOCKER_BUILD_EXPORT_RETENTION_DAYS envs; neither appears anywhere in the repo. Every input in use — context, file, push, tags, platforms, cache-from, cache-to — is unchanged.

setup-buildx-action v4 removed deprecated inputs and outputs (#464). It's invoked with no inputs, and its outputs can't be referenced — the step has no id.

login-action v4, setup-qemu-action v4 and setup-helm v5 are Node 24 + ESM only. login-action's registry/username/password are unchanged; the other two take no inputs at all.

All runners are GitHub-hosted (ubuntu-latest / ubuntu-24.04), so the ≥ 2.327.1 runner requirement is already met.

Two things the bump changed that the version numbers don't show

The build summary is not free, and the bump turned it on silently. build-push-action v6+ generates a summary and uploads a build-record artifact per build. release-traceway.yml runs five builds, so this bump quietly adds five artifacts per release, inheriting the repo-wide retention.

Kept rather than disabled — all five builds write cache-to: type=gha,mode=max, and the summary panel is the only place per-build cache-hit ratios and step timings show up without re-running a 30-minute release. Bounded instead with DOCKER_BUILD_RECORD_RETENTION_DAYS: 7 at the job level: a week is long enough to debug the release that produced them. (That is the v7 spelling; v7 removed the older DOCKER_BUILD_EXPORT_RETENTION_DAYS name.)

The wranglerVersion comments no longer defer across files. Two of the three said "See release-website.yml" for their rationale, which is a coupling nothing enforces — each of these files is normally read alone in a diff, and rewording or retiring the website comment would silently orphan two pointers. Each site now states its own reason and points at #331.

Refs #326.

🤖 Generated with Claude Code

[FrameAutomata]

Aligned the release-helm.yml Wrangler pin with #347, which closes #331 by putting the CLI version in website/ and docs/ package-lock.json.

Two things that changed here:

"3" → "3.114.17". A bare major is a range wrangler-action re-resolves on every deploy, so it bounded the major and nothing else — which is most of what #331 was complaining about.

The with: block is now byte-identical to #347's. The only line that differs between the two branches in this file is @v3 → @v4, which is what this PR is for. So the two merge in either order without a conflict.

The wranglerVersion pins on release-docs.yml and release-website.yml stay. They are the safety net if this lands before #347 — without them, @v4 unpinned would take Wrangler 4 onto a production deploy. Once #347 is in, the installed 3.114.17 satisfies "3" and the lockfile decides anyway (installWrangler accepts an installed version that satisfies the input), so they become redundant rather than wrong, and a follow-up can drop them.

---

Generated by Claude Code