ci: set cache-mode on release workflows

[claude]

Requested by David Sanders · Slack thread

Before: On a push to main, the Release workflow runs the test job (via test.yml, whose setup-node step uses cache: 'yarn') and then the release job. Nothing in the workflow itself forbids cache access; the release job only avoids the cache because its own setup-node step sets package-manager-cache: false, and the reused test job still restores and saves the yarn cache during release runs.

After: The Release workflow declares cache-mode: none at the top level, so no job in a release run can read from or write to the Actions cache, regardless of what individual steps ask for. Because the test job calls test.yml via uses:, the caller's none also caps that called workflow during release runs: its cache: 'yarn' restore is skipped and reported as a cache miss, and the save is a no-op. PR CI (test.yml triggered directly) is untouched and keeps caching.

GitHub added a workflow- and job-level cache-mode key that enforces cache access declaratively; see the changelog and the workflow syntax reference.

How: Adds a one-line comment and cache-mode: none directly after the top-level permissions: {} block in .github/workflows/release.yml. The existing package-manager-cache: false line is left in place. Note that PR CI does not exercise the release workflow, so the first release after merge is the real test; if a step is denied cache access, actions/cache and the @actions/cache toolkit log a message and continue rather than failing the job.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MYe3WCXtgiqomNuVQdi4Yd

---

Generated by Claude Code

[claude]

I reviewed this PR and didn't find any confirmed bugs, but because this change touches the release workflow and depends on a GitHub Actions key I can't independently verify, a human look is still worthwhile before merging.

What was reviewed:

• The one-line diff adding cache-mode: none plus a comment to .github/workflows/release.yml, placed right after the top-level permissions: {} block.
• Whether cache-mode is a key GitHub Actions recognizes at the workflow top level versus one that would cause the whole workflow file to be rejected as invalid if unsupported — this isn't verifiable from this environment.
• Confirmed the change is purely additive config (a comment and one key); no job/step logic, permissions, or secrets handling were touched.

Extended reasoning...

The diff only touches .github/workflows/release.yml, adding a one-line cache-mode: none key (with a comment) right after permissions: {}, before jobs:; nothing else in the pipeline (job logic, permissions, secrets) changed. The PR description cites a GitHub changelog dated 2026-09-10 announcing this as a new top-level/job-level workflow key, which postdates this review's ability to verify from documented knowledge, and the key is not one I have confirmed in GitHub's established workflow schema. Unknown top-level keys in GitHub Actions workflows have historically caused the entire workflow file to be rejected as invalid rather than silently ignored, which would be a more severe failure mode (no releases trigger at all) than the cache-miss behavior the PR description anticipates. This is the repo's release pipeline, a critical path, and the bug hunter's own candidate note on this exact line was only dismissed as a duplicate rather than independently confirmed safe, so I'm deferring rather than approving.

[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: changelog and workflow syntax reference. An unknown key would indeed fail workflow parsing, but this one is in the current schema. The same top-level cache-mode: none already runs on main in 18 merged electron repos, including lint-roller, whose 4.0.0 release run 35411297569 logged Cache mode: none.

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