Skip to content

ci: set cache-mode on release workflows #4370

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
claude wants to merge 1 commit into
base: 7.x
Choose a base branch
from
+6 −0
Open

ci: set cache-mode on release workflows #4370

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/gh-pages.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,9 @@ on:

permissions: {}

# Release paths never touch the Actions cache; enforced regardless of per-step settings.
cache-mode: none

jobs:
deploy:
runs-on: ubuntu-latest
Expand Down
3 changes: 3 additions & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,9 @@ on:

permissions: {}

# Release paths never touch the Actions cache; enforced regardless of per-step settings.
cache-mode: none
Comment on lines +10 to +11

@claude claude Bot Sep 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Adding cache-mode: none at the workflow root can make GitHub treat the whole workflow file as invalid, so maintainers get zero npm publishes/GitHub releases after merge instead of the intended cache lockdown. GitHub's Actions parser enforces a fixed schema for the workflow root (name, on, permissions, env, defaults, concurrency, jobs) and rejects unknown top-level keys with "Unexpected value ''", failing validation before any job runs; cache-mode is not a documented workflow-level key. If that happens here, every push to main after a version bump fails validation and check-release-criteria/publish never execute, silently breaking releases. The same key is added at .github/workflows/gh-pages.yml:12, so a v7.* tag push would likewise never trigger docs deploy. …

Extended reasoning...

…Fix: verify cache-mode is an actual, currently-supported top-level workflow key before merging (it is not part of the schema as of this reviewer's knowledge); if unsupported, remove it and rely on the existing package-manager-cache:false/actions/cache exclusions instead.

GitHub validates each workflow YAML against a schema that only allows name, run-name, on, permissions, env, defaults, concurrency, jobs at the root; additional properties are rejected with an 'Unexpected value' validation error shown in the Actions tab, and none of the jobs run for that trigger. release.yml:10-11 and gh-pages.yml:11-12 both add cache-mode: none at that root level. If this key is not a real, currently-recognized field (the PR's zizmor 1.30.1 check only validates security lint rules, not GitHub's own workflow schema, so it would not catch this), the next push to main matching the release commit pattern fails workflow validation entirely: check-release-criteria and publish never run, so no npm publish and no GitHub release are created. Likewise the next v7.* tag push never runs gh-pages.yml's deploy job, so…

Verification: normal. The diff inserts cache-mode: none at the workflow root (release.yml:11 and gh-pages.yml:11), as a sibling of on:/permissions:/jobs:. GitHub Actions validates each workflow against a closed root schema (only name, run-name, on, permissions, env, defaults, concurrency, jobs); an unrecognized top-level property triggers a hard "Invalid workflow file … Unexpected value…


jobs:
check-release-criteria:
name: Check Release Criteria
Expand Down
Loading