ci(codeql): switch to advanced setup so fork pull requests get scanned - #53
Merged
Merged
Conversation
GitHub's code scanning default setup never triggers on a pull request from a fork. Pull request #50, from wangdahoo/kaas, therefore sat permanently blocked: the "main" ruleset requires a CodeQL result, and no CodeQL run was ever created for its head or its merge commit. Every same-repo pull request from #32 to #51 got one; both fork pull requests got none. A workflow file is part of the pull request's merge commit, so it also runs for fork pull requests, subject to the usual approval for outside contributors. The matrix reproduces the four analyses and build modes default setup ran, so the languages covered do not change. Default setup has to be turned off for this to work: while both are active the upload fails with "CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled".
tybot02
approved these changes
Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Merging #50 is blocked on
Code scanning is waiting for results from CodeQL for the commits ae58a4d or d0b2f35— and those results were never going to arrive.CodeQL was on default setup, which does not trigger on pull requests from forks. The evidence:
code-scanning/analyses?ref=refs/pull/50/head[]code-scanning/analyses?ref=refs/pull/50/merge[]d0b2f35(head)ae58a4d(=merge_commit_sha)actions/runs?event=dynamicPR #NNCodeQL run for #32 through #51 — none for #50#50 and #52 are the only cross-repository pull requests in that range, and they are exactly the two with no CodeQL run. This is not the outside-contributor approval gate: #52's Tests and Docker runs do sit in the
action_requiredqueue, but no CodeQL run is queued there at all — the run is never created.Since the
mainruleset has acode_scanningrule requiring a CodeQL result, every fork pull request is permanently unmergeable.Fix
Advanced setup. A workflow file is part of the pull request's merge commit, so it runs for fork pull requests too, after the usual approval for outside contributors.
Verified empirically rather than from documentation:
prettier/prettieruses advanced setup with apull_requesttrigger, and its fork pull requests (e.g. #19908, #19907) each carry aCodeQLcheck reportingNo new alerts in code changed by this pull request— the check produced by a successful SARIF upload, which is what the ruleset consumes.The matrix reproduces default setup's four analyses and their build modes (
actions,govia autobuild,javascript-typescript,python), so language coverage is unchanged. Default setup's language list also namedjavascriptandtypescript, which CodeQL folds intojavascript-typescript.Default setup is already disabled
It had to be, and before this branch was pushed: while both configurations are active the upload fails with
CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled, whichcodeql-actionraises as aConfigurationError(src/upload-lib.ts), failing the job. Landing the workflow first would have deadlocked on its own pull request.The repository had 0 open code scanning alerts at the time of the switch, so nothing active was lost. Re-enabling is one API call if this needs to be reverted.
After this lands
#50 and #52 need a new
pull_requestevent to pick up the workflow — a rebase or a close/reopen — and their runs then need the outside-contributor approval.