ci: set cache-mode on release workflows

[claude]

Requested by David Sanders · Slack thread

Before: A release run (push to main) or a docs-publish run (push of a v* tag) could restore from or save to the GitHub Actions cache if any step asked for it. Today the release jobs opt out per step via package-manager-cache: false, but that protection lives in each step's inputs and silently disappears if a step is added or changed. The test job that release.yml calls via uses: runs with whatever cache access test.yml requests.

After: Both release.yml and docs.yml declare cache-mode: none at the workflow level, so no job or step in those runs can read or write the Actions cache, whatever the individual steps say. Because release.yml calls test.yml via uses:, the caller's none also caps the called test jobs during release runs; the same test.yml keeps its normal caching when it runs for pull requests. The existing package-manager-cache: false lines are left in place.

GitHub now offers a workflow-level cache-mode key that enforces this at the runner rather than per step, so release paths are guaranteed never to consume a cache entry a PR run could have poisoned; see the changelog and the workflow syntax reference.

How: Adds a top-level cache-mode: none (with a one-line comment) directly after the permissions: block in .github/workflows/release.yml and .github/workflows/docs.yml. Nothing else changes; test.yml is untouched so PR CI keeps caching.

Note that PR CI does not exercise the release or docs workflows, so the first release (and first tag push) after merge is the real test. If a step is denied cache access under this mode, actions/cache and the @actions/cache toolkit log a message and continue (a skipped restore behaves as a cache miss, a skipped save is a no-op), so the run does not fail.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MYe3WCXtgiqomNuVQdi4Yd

---

Generated by Claude Code

[claude]

I reviewed this PR and didn't find any bugs via the standard checks. Because the whole change hinges on a workflow-level cache-mode: none key that I cannot confirm is part of the documented GitHub Actions workflow schema, a human should verify that key is actually recognized before relying on it (release paths are the second affected feature here, so an unrecognized key either makes the stated protection a no-op or, if GitHub's schema validator rejects unknown top-level keys, could break these workflows outright).

What was reviewed: the two added blocks (comment + cache-mode: none) in docs.yml and release.yml, their placement right after permissions: {}, and that nothing else in either workflow (jobs, steps, the existing package-manager-cache: false lines, the uses: test.yml call) was touched.

Extended reasoning...

The diff adds an identical 2-line block (a comment plus cache-mode: none) to the top level of both .github/workflows/docs.yml and .github/workflows/release.yml, right after permissions: {}; nothing else changes, and no job/step logic is touched, so there is no injection, auth, or permissions-elevation surface here. The deciding fact for defer is that cache-mode does not match any top-level GitHub Actions workflow key I'm aware of (name, on, permissions, env, defaults, concurrency, jobs, etc.), and the PR's entire stated purpose — guaranteeing release/docs runs can never touch the Actions cache — depends on GitHub actually supporting this key; a human with current access to GitHub's live schema/docs should confirm it before trusting the comment's claim or merging further workflow changes on top of it. A maintainer already approved this PR, but that doesn't by itself establish the key was fact-checked, so flagging it is still useful.

[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 or docs.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