Repository navigation
ci(security): stop declaring advanced CodeQL; default setup owns it - #143
Conversation
The reusable security-scan's CodeQL job ran on every push, PR and weekly schedule, and every upload it produced was refused by code scanning: Analysis upload status is failed. CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled CodeQL job status was configuration error. It still reported green, because the reusable carries continue-on-error on the Analyze step and the rejection is emitted in the post-job phase. Coverage is unchanged. Default setup runs the extended query suite, which is broader than the default suite this workflow used. Omitting `languages:` leaves the reusable's '[]' default, and its `if: inputs.languages != '' && inputs.languages != '[]'` gate skips the job rather than failing it.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe security workflow no longer passes an explicit language list to the reusable security-scan workflow. Comments describe the empty-list default and note that GitHub default setup continues code scanning. ChangesSecurity scan configuration
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~4 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The reusable CodeQL job is skipped, with coverage intended to come from GitHub default setup. This checkout cannot confirm that setting, but no code-scanning gap is established by the available evidence. Architecture SummaryArchitecture risk: 🔵 Low · up to The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency. Changed systems: None identified. Architecture concerns Review detailsBefore / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Verified on this PR's own checks
The reusable's So: the discarded advanced analysis is gone, and CodeQL scanning is not. |
1 participant
What this does
Drops
languages:from thesecurity.ymlcall into the org reusablesecurity-scan.yml, so this repo stops declaring an advanced CodeQLconfiguration. CodeQL coverage here continues, unchanged, via GitHub's
default setup.
What was actually happening
Code scanning rejected every upload the advanced job produced. From the
CodeQL job of run
36643939241:This is not a guess about the config — it is the stored state. Every CodeQL
analysis stored on this repository carries default setup's analysis key:
Not one carries a workflow's
analysis_key— the advanced job has never landeda result here. Check it for yourself with
GET /repos/resq-software/docs/code-scanning/analyses, grouped byanalysis_key.SARIF upload works generally — the zizmor SARIF from these same workflow runs
uploads fine. It is CodeQL specifically that is refused, because
code-scanning/default-setupon this repo reportsstate: configured, withquery suite
extended.Why it reported green
The org reusable carries, on the Analyze step:
and the
##[error]is emitted by thatAnalyzestep itself, in its mainphase — which is exactly what
continue-on-error: trueon that stepswallows. Had the rejection genuinely been post-job, a
continue-on-erroronthe step could not have masked it. The ordering is visible in the run log
linked above: the
##[error]sits inside theAnalyzestep's own output,ahead of the first
Post job cleanup.line. Only the trailingCodeQL job status was ...line is printed after the step, byinit-post, and a passingrun prints it too, reading
was success.Positive control: on
resq-software/programs, where default setup is off, thesame reusable logs
Analysis upload status is complete.andCodeQL job status was success., with no##[error]anywhere in theAnalyzestep.The
Analyzestep's own APIconclusionstill readssuccess. A permanentconfiguration error was rendered as a permanent green check for scanning that
never landed.
Coverage is not reduced
Default setup runs the
extendedquery suite. The reusable's CodeQL jobpasses no
queries:,packs:orconfig-filetocodeql-action/init, so itran the default suite — a subset of
extended. The discarded work was alsothe narrower work. This PR removes waste and a false signal; it does not remove
scanning.
Why omitting the input is safe
The reusable gates the job on the input being non-empty:
languagesdefaults to"[]", so omitting it makes the job skip, notfail. Confirmed on this PR's own checks below rather than assumed.
Scope / blast radius
security.ymlwas the only CodeQL declaration in this repo — nocodeql.yml, nocodeql-languages:passed to the orgrequired.yml, and nogithub/codeql-action/initanywhere else under.github/.default-branch-baselineruleset requires only the
requiredcontext.as it is.
resq-software/crateshas defaultsetup off, and its advanced CodeQL job reports
Analysis upload status is completeand stores analyses under its own workflow'sanalysis_key.cratesandprogramsare deliberately untouched — their workflows are thereal coverage there.
Follow-up (separate PR, deliberately after this one)
Once this collision is gone across the affected repos, the
continue-on-error: trueshould come off the reusable's Analyze step so areal CodeQL failure fails loudly again. Ordering matters: removing it first
would convert a silent failure into a hard failure on every affected repo at
once. Mitigating but not sufficient — every consumer pins the reusable by SHA
and that repo has no tags, so a change there reaches nobody until they re-pin.
Test plan
securityworkflow runs on this PRCodeQL (...)job(s) report skipped, not failedSummary by CodeRabbit