fix(ci): grant actions: read so the security workflow can start - #118
Conversation
An explicit permissions block sets every unlisted scope to none, so the reusable security-scan workflow's CodeQL and SARIF-upload jobs were requesting more than this caller granted. GitHub rejects that at run creation, which is why every run of this workflow has been startup_failure rather than a normal failure — no job ever started, and no logs were produced. npm, dotnet-sdk, landing, research and programs already carry this line and their scans pass; crates, dev, docs and viz do not and all fail. The rationale comment is copied verbatim from the repos that already had it. Read-only; grants no write capability.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe security workflow now grants ChangesSecurity workflow permissions
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
This repo's
securityworkflow has never run. Every invocation ends instartup_failure— GitHub rejects the run at creation, so no job starts and no logs are produced. That is why it was invisible in normal triage:startup_failureis not in the default status set most tooling scans for, and there is nothing to read even when you find it.Root cause
security.ymlis a thin caller for the org-wide reusable workflowresq-software/.github/.github/workflows/security-scan.yml. That workflow's CodeQL and SARIF-upload jobs declareactions: read.An explicit
permissions:block sets every unlisted scope tonone. Since the caller listed onlycontents,security-eventsandpull-requests, the nested jobs requested a permission the caller did not grant — and GitHub refuses to create the run.Evidence
The correlation across the org is exact, with no exceptions:
actions: readsecurityrunRuled out along the way: the pinned reusable-workflow SHA resolves and the file exists at it; the
languages/submodulesinputs are declared and correctly typed; the reusable workflow's ownpermissionsblock matches the caller's other three scopes;resq-software/.githubis public, so repo access policy does not apply. Notably the working and broken repos pin the same SHA — so it is the caller, not the callee.Fix
One line, plus the rationale comment copied verbatim from the repos that already had it — this was diagnosed once before and simply never propagated to the other four.
Read-only. Grants no write capability.
Verification
actionlintcleanpermissions.actions == "read"securityshould now actually start and run instead ofstartup_failureCompanion PRs opened against
crates,dev,docsandviz— all four carry the identical change.Summary by CodeRabbit