Repository navigation
[AAASM-6185] 🔧 (ci): Migrate CodeQL to advanced setup so Dependabot heads are analysed - #72
Conversation
Default setup never analyses a pull request whose head commit is authored by dependabot[bot] — the managed analysis run is not created, while the CodeQL check still posts conclusion=neutral / "N configurations not found". Not red, not blocking, and it reads as scanned. Advanced setup analyses bot heads normally, as verified in-org on python-sdk #344 and #341. Language list mirrors this repository's own default-setup configuration: actions, python. Refs AAASM-6185 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured on this migration: with default setup still enabled the analysis runs to completion and only the SARIF upload is refused -- CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled -- which presents as a red Analyze (...) job beside a green managed one. Default setup has now been disabled on this repository. Recording the ordering in the file so re-enabling it is recognisable as the cause rather than rediscovered. Refs AAASM-6185 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Chisanan232
left a comment
There was a problem hiding this comment.
Self-review (COMMENT event; GitHub blocks approving one's own PR, so this is the substantive review under the standing solo-maintainer arrangement).
Same migration as the sibling repos: a committed .github/workflows/codeql.yml replacing default setup, with the language set matching what default setup already analysed here (actions, python). Checked that the existing no hardcoded value contradicts the registry gate is untouched and still reports success, since this repo's own governance checks are the thing most at risk from an ill-considered workflow addition.
No continue-on-error, no narrowed queries, no paths filter. Real rule evaluation observed on this head.
Protection settings, CODEOWNERS and the required check set are all left exactly as they are.
Chisanan232
left a comment
There was a problem hiding this comment.
Review of record under the repository's solo-maintainer arrangement (APPROVE returns 422 on one's own PR; .github/CODEOWNERS is * @Chisanan232, the only collaborator, so no account in existence can supply the required approving review). True merge commit — squash and rebase are disabled repository-wide, so the merge method is not a choice.
Correcting my own earlier assessment. I had recorded this PR as awaiting a founder decision on the grounds that an admin merge on a self-authored PR differed from the merges already made in this sweep. That rested on an unchecked fact. Protection here is required_approving_review_count: 1, require_code_owner_reviews: true, enforce_admins: false, required_status_checks.contexts: null, with exactly one collaborator — so the approval is unobtainable rather than absent, and enforce_admins: false is the configuration that deliberately makes the documented route available. Standing arrangement, authorised 2026-08-05.
This repository is the honest exception in the migration, and I am stating that plainly rather than reusing the other two PRs' evidence. The defect this change fixes is that a head commit authored by dependabot[bot] is never analysed under default setup. That was measured on the sibling PRs — docs#168 (neutral, "2 configurations not found", zero analysis runs) against docs#169 (same bot branch, head commit re-authored by a human merge, fully analysed), and homebrew-tap#67 and #64 (neutral, "3 configurations not found", zero analysis runs). Here there is no such evidence, because:
.github/dependabot.yml on main |
absent (404) |
| Dependabot PRs ever opened in this repository | 0 — all recent PRs are Chisanan232-authored |
So in this repository the change is preventative, not a repair of an observed hole. The exposure it forecloses is real — this repo holds org-wide workflow and rules content, and the moment Dependabot is enabled here (or a bot-authored commit lands by any other route) the gap would apply identically, with the same non-red neutral presentation. But nothing here has yet merged unanalysed on that path, and the ticket's record should not imply otherwise.
There is a second, independent reason the change stands on its own merits here: default setup analysed nothing at all in this repository until this workflow, because default setup was already not-configured while no advanced workflow existed — so main currently has no CodeQL coverage whatsoever. .github/workflows/codeql.yml returns 404 on main. This PR is the coverage, not an upgrade to it.
The migration-order hazard is discharged. The file warns default setup must be disabled before this workflow can upload, or the upload is refused and shows as a red Analyze job beside a green managed one. GET /code-scanning/default-setup reports state: not-configured, and the uploads on this head succeeded, which is the confirmation that matters.
Real analysis, not a decorative check, measured on this head's merge commit 437c77005:
| Category | Rules run | Results | CLI |
|---|---|---|---|
/language:python |
43 | 0 | 2.27.1 |
/language:actions |
17 | 0 | 2.27.1 |
actions is the one that earns its place here: this repository's substance is workflows and reusable CI, and those 17 rules cover excessive GITHUB_TOKEN scope, untrusted-input injection and unpinned actions — the failure classes this repo can propagate org-wide. (A pull_request run uploads against refs/pull/72/merge, not .../head.)
The reporting path demonstrably emits findings. Across the org's already-advanced repositories CodeQL has raised 78 real alerts (rust/cleartext-logging 39, rust/cleartext-transmission 17, rust/hard-coded-cryptographic-value 19 critical, and four others), so results_count: 0 here is a verdict rather than an incapacity.
The configuration matches this repository. Language list is actions and python, exactly the former default-setup configuration (languages: ["actions","python"]). Verified as a pair, not assumed — and it differs from homebrew-tap's three-language list in the same migration, which is where a blind copy would have shown.
Pins verified by dereferencing the tags: actions/checkout@3d3c42e5… matches v7.0.1; github/codeql-action@65216971… matches codeql-bundle-v2.25.2. Both tag objects are commits, so no annotated-tag indirection.
No paths filter, deliberately — a source-scoped filter would silently re-create the gap for exactly the manifest-and-lockfile changes this exists to catch. pull_request unqualified, push on main, weekly schedule.
Nothing is weakened. required_status_checks.contexts is null before and after; no check made required or non-required, no job condition loosened, no test skipped or relaxed. The change adds a workflow and removes nothing.
Gate state at the head 5c161fcd966feffc88503c91db67b56ce0b9aa3f: 6 check runs — 6 success, 0 skipped, 0 failure, 0 cancelled, 0 neutral. That includes this repo's own no hardcoded value contradicts the registry gate, which is green, so the workflow addition does not disturb the registry-consistency contract. Head SHA re-read immediately before merging.
One observation, not a blocker. The SHA pin does not pin the analysis toolchain: the pinned commit's src/defaults.json declares cliVersion: 2.25.1, yet the runs used CodeQL 2.27.1, resolved at runtime from a bundle URL the action constructs. This is worth knowing in this repository in particular, since it is the one whose CI content other repositories imitate — the pin makes the action code reproducible, not the queries. Deliberately unchanged: a tools: input would freeze the security queries, the worse failure mode for a scanning workflow.
Evidence is textual by deliberate choice, per this workstation's data-handling policy.



What changed
Adds
.github/workflows/codeql.yml— CodeQL advanced setup. As a follow-up step outside this diff, CodeQL default setup is then disabled on this repository.One new file. No existing workflow, test, branch-protection setting or required-check list is touched.
Why
Under default setup, a pull request whose head commit is authored by
dependabot[bot]is never analysed. The GitHub-managed run atdynamic/github-code-scanning/codeqlis not created at all, yet the CodeQL check still postsconclusion=neutralwith the titleN configurations not found— where N equals the repository's own language-configuration count, i.e. no configuration produced an analysis. That is not red, does not block a merge, and on the pull-request page reads as though scanning happened.Measured across the 18 Dependabot pull requests created after their repository's default-setup date, in the four repositories that have had one:
dependabot[bot]Zero exceptions in either direction. The discriminator is the head commit author, not the pull-request author —
ai-agent-assembly/docs#169 is a Dependabot pull request and was fully analysed, because its head commit is a human merge-of-main.This repository is affected by configuration rather than by observation: it is on default setup, but has had no Dependabot pull request since its setup date, so there is nothing to have measured here yet. It would behave identically on its next bump. Stated this way deliberately rather than implying measured breakage.
Why advanced setup fixes it
ai-agent-assembly/python-sdkalready runs advanced setup. Two Dependabot pull requests there, both withdependabot[bot]head commits — so the variable that breaks default setup is held constant — are analysed in full: #344 (9 files) and #341 (uv.lockonly), each producingCodeQL | path=.github/workflows/codeql.yml | event=pull_request | conclusion=successplus a passingAnalyze (…)check per language.Scope choices, stated explicitly
code-scanning/default-setupresponse:actions, python. Language lists differ per repository and are not copied between them. Where default setup listedjavascript,typescriptandjavascript-typescriptseparately, those are aliases of one extractor, sojavascript-typescriptalone is identical coverage, not reduced coverage.pathsfilter, deliberately. A Dependabot pull request changes only a manifest or a lockfile; a paths filter is the most likely way to silently re-create the gap this file closes.neutralCodeQL check was never gating anything. Replacing a decorative check with a real analysis removes no gate, adds no bypass, and does not touch the review requirement or CODEOWNERS.build-mode: nonefollow the in-org reference workflow (python-sdk) exactly.How to verify
Analyze (…)check per language withevent=pull_request,path=.github/workflows/codeql.yml.N configurations not foundcan no longer be produced on any pull request here.Refs AAASM-6185