ci: set cache-mode on release workflows

[claude]

Requested by David Sanders · Slack thread

Before: Whether a release run touched the GitHub Actions cache depended on per-step configuration. The Release workflow (tag push v*) opts out of caching step by step (package-manager-cache: false on every setup-node), and the test job it calls via uses: ./.github/workflows/test.yml runs with whatever cache settings test.yml has. Nothing enforced the "no cache on release" intent at the workflow level, so a future step or action that restored a cache entry would silently be allowed.

After: The Release workflow declares cache-mode: none at the top level, so every job in a release run — including the test jobs pulled in from test.yml via uses: — is denied cache access by the runner regardless of what individual steps or actions ask for. A denied cache restore logs a message and continues as a cache miss; a denied cache save logs and becomes a no-op, so the release does not fail because of this setting. PR CI (ci.yml, test.yml, build.yml) is untouched and keeps caching as before.

GitHub's new workflow-level cache-mode key makes this a declarative, enforced setting rather than a convention (see changelog and workflow syntax reference), which closes the cache-poisoning avenue on the path that publishes signed binaries.

How: Adds cache-mode: none (with a one-line comment) directly after the top-level permissions: {} block in .github/workflows/release.yml. No other lines changed; the existing package-manager-cache: false lines are kept. The file parses as YAML and zizmor 1.30.1 accepts the new key with no new findings. Note that PR CI does not exercise the release workflow, so the first tagged release after merge is the real test of this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MYe3WCXtgiqomNuVQdi4Yd

---

Generated by Claude Code

[coveralls]

coverage: 87.336%. remained the same — ci/cache-mode into main

[claude]

I reviewed this PR and the automated bug hunt found no bugs, but a human should double-check one specific factual claim before merging: cache-mode: none as a top-level GitHub Actions workflow key. This sandbox has no network access, so I could not verify it against the GitHub docs/changelog the PR cites, and it does not match the workflow-level keys I'm otherwise aware of (name, run-name, on, permissions, env, defaults, concurrency, jobs). If it isn't a real, currently-shipped key, GitHub's workflow parser would likely reject the whole file as invalid rather than silently ignore it — which would break every future tagged release (the path that publishes signed binaries).

What was reviewed:

• The 3 added lines in release.yml: comment plus cache-mode: none placed right after permissions: {}.
• Checked for existing CI validation of workflow schema against GitHub's live parser (e.g. actionlint/zizmor) — the only zizmor references in this file are inline # zizmor: ignore[...] suppression comments, not a schema-validating CI step.
• Confirmed the PR's own description states PR CI never exercises the release workflow, so this change is untested until the next tag push.
• Verified the pre-existing per-step package-manager-cache: false settings on setup-node are unchanged by this diff.

Extended reasoning...

Overview

The diff adds three lines to .github/workflows/release.yml: a comment and a new top-level key cache-mode: none, placed after the existing permissions: {} block. No job/step logic changes; the existing per-step package-manager-cache: false settings on setup-node are untouched.

Security risks

The stated intent (deny Actions cache read/write across the whole release workflow, including reused test.yml jobs) is a reasonable hardening goal for a workflow that publishes signed binaries — cache poisoning on a release path is a legitimate threat model. The risk is the opposite of the usual security review concern: this isn't a change that grants excess permissions or leaks secrets, it's a change whose entire value depends on a GitHub Actions feature (cache-mode as a top-level workflow key) that I cannot verify exists. I have no record of this key in GitHub's workflow syntax as of my knowledge cutoff (Jan 2026), and this sandbox has no network access to check the specific changelog/docs URLs the PR cites (dated 2026-09-10, i.e. very recent relative to "today"). If the key is not real, the practical effect is not "no-op" but likely "invalid workflow file," which would block every future tagged release until fixed — a worse outcome than the status quo, on the one workflow that ships signed binaries to users.

Level of scrutiny

This warrants more than a rubber-stamp despite being only 3 added lines, because: (1) it touches the release/signing pipeline, a CODEOWNER-sensitive, high-blast-radius path; (2) the author's own PR description admits PR CI never exercises the release workflow, so "the first tagged release after merge is the real test" — there is no automated proof this doesn't break releases; and (3) I could not independently confirm the core factual premise (that cache-mode is a real, shipped workflow key) due to lack of network access in this review environment.

Other factors

No CI job in this repo validates the release workflow's YAML against GitHub's actual schema before merge — the only zizmor references in the file are inline suppression comments for a different check, not a schema-validating pipeline step, so an invalid top-level key would not be caught pre-merge. This, combined with the untestable nature of the change until the next real tag push, is why I'm asking a human to confirm the key is genuine before this merges, rather than approving on the strength of the diff's small size alone.

[claude]

Confirming the reviewer's open question: cache-mode is a shipped, generally available workflow-syntax key as of 2026-09-10, valid at the workflow top level and at jobs.<job_id>.cache-mode, with values read, write, write-only, and none. Sources: the changelog and the workflow syntax reference. An unknown key would indeed fail workflow parsing, but this one is in the current schema.

As noted in the description, PR CI does not run release.yml, so the first tagged release after merge is the first real exercise of the setting. Per the docs, a cache operation not permitted under none "logs an informational message and continues. The job and workflow do not fail."

---

Generated by Claude Code

[MarshallOfSound]

Bypass merge via Orbital by @MarshallOfSound.

idk why this is blocked, some weird ruleset?

This merge bypassed required checks / rules; the reason above was recorded first.