fix(ci): unblock the release workflow (reusable-workflow permission startup failure)#232
Conversation
Release-and-Publish startup_failed on both pull_request:closed and workflow_dispatch after #228, so 2.2.0 never published. Root cause: #228 added a "changes" job to the reusable Build Module.yml that declares pull-requests: read. Release calls that workflow via uses:, and its build-and-test caller granted only contents: read + security-events: write. A reusable workflow's jobs may not request permissions the caller did not grant; GitHub validates this STATICALLY at startup (before any if: skip), so even though "changes" is skipped on the workflow_call path, the excess request fails the whole run before it starts. Grant pull-requests: read on the caller so static validation passes. The permission is unused on the release path (the "changes" job is skipped there) and is read-only and minimal. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Up to standards ✅🟢 Issues
|
There was a problem hiding this comment.
Pull request overview
Fixes a startup_failure that blocked the 2.2.0 release by adding the pull-requests: read permission to the build-and-test caller job in Release-and-Publish.yml. The reusable Build Module.yml (introduced in #228) declares a changes job with pull-requests: read, and GitHub validates reusable-workflow permissions statically at startup — so even though the job is skipped on the release path, the missing caller permission rejected the entire workflow.
Changes:
- Grants
pull-requests: readto thebuild-and-testjob that callsBuild Module.yml. - Adds a comment explaining why the permission must remain even though it appears unused on the release path.
Why
Release-and-Publishstartup_failed on bothpull_request: closed(run 26821404801) andworkflow_dispatch(run 26821603517) after #228 merged, so 2.2.0 never published. A startup failure means the workflow file is rejected before any job runs.Root cause
#228 added a
changesjob to the reusableBuild Module.ymlthat declares:Release-and-Publish.ymlcalls that workflow viauses: ./.github/workflows/Build Module.yml, and itsbuild-and-testcaller granted onlycontents: read+security-events: write.A reusable workflow's jobs may not request permissions the caller did not grant (docs: "permissions can only be maintained or reduced—not elevated"). GitHub validates this statically at startup, before any
if:skip is evaluated — so even thoughchangesis skipped on theworkflow_call(release) path, its excesspull-requests: readrequest fails the entire run before it starts. That's why both triggers failed deterministically, while direct-PR runs ofBuild Module.yml(no caller cap) were unaffected. The 2.1.2 release (nochangesjob) worked.Fix
Grant
pull-requests: readon thebuild-and-testcaller so static validation passes. The permission is unused on the release path (thechangesjob is skipped there) and is read-only and minimal. Comment added explaining why a future reader must not remove it.Scope / safety
.github/workflows/**) — it is excluded from the release path filter, so merging this does not itself publish a gallery version.workflow_dispatchof Release-and-Publish (or by the next bundle PR).Not in this PR
The unresolved Codex P2 on #231 ("include the policy in release triggers") is a separate, valid concern about which future edits trigger a publish. Tracked and replied to on #231; addressed separately so this stays a focused startup fix.