Skip to content

ci(codeql): let the scan be triggered on demand - #116

Merged
bgard68 merged 1 commit into
mainfrom
ci/codeql-manual-trigger
Sep 11, 2026
Merged

bgard68 merged 1 commit into
mainfrom
ci/codeql-manual-trigger

Conversation

@bgard68

@bgard68 bgard68 commented Sep 11, 2026

Copy link
Copy Markdown
Owner

Adds workflow_dispatch to the CodeQL workflow. One line of behaviour change: a Run workflow button in the Actions tab. Same security-extended suite, same two languages, same SARIF upload to Security → Code scanning.

Why

The security tab currently reports this configuration as "Actions workflow not enabled", while the analyses it lists are real and current — both csharp and javascript-typescript scanned 8c94ecf (the tip of main) and returned 0 open alerts.

Those two statements can't both be right, and there's no way to find out which is stale. Every existing trigger waits on an event — a push to main, a pull request, or Monday 07:13 UTC — so the configuration can only be probed by opening a PR and seeing whether the Analyze checks show up. This makes it a button press.

Worth noting alongside it: the Actions API registers only 6 of the 11 workflows committed on origin/main, and reports zero runs for any of them, including ones observed running. codeql.yml, ci.yml, dependency-review.yml, secret-scan.yml and web-ci.yml are the five missing. SHA pinning was ruled out as the cause — sha_pinning_required is on and all 11 workflows are fully pinned. This PR doesn't claim to fix that; it makes it diagnosable.

Note on the trigger

No paths-ignore on workflow_dispatch, unlike push and pull_request. Asking for a run by hand is an explicit request for a full scan; skipping it because the last commit touched a markdown file would defeat the purpose.

The if: github.event.repository.visibility == 'public' guard is unchanged and still applies — github.event.repository is populated on dispatch events, and the repo is public.

🤖 Generated with Claude Code

The security tab reports this configuration as "Actions workflow not enabled"
while the analyses it lists are real and current — both languages scanned the
tip of main and returned no alerts. One of those two statements is stale and
there is currently no way to find out which.

Every existing trigger waits on an event: a push to main, a pull request, or
Monday. None can be asked a question. workflow_dispatch adds the button, so the
configuration can be confirmed directly instead of inferred from whether checks
appear on the next PR.

No paths-ignore on the manual trigger, unlike push and pull_request: asking for
a run by hand is an explicit request for a full scan, and skipping it because
the last commit touched a markdown file would defeat the point.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@bgard68
bgard68 merged commit 0b2248f into main Sep 11, 2026
8 checks passed
bgard68 added a commit that referenced this pull request Sep 11, 2026
Extends the CodeQL change in #116 to the three other workflows that can run
standalone. Adds workflow_dispatch to ci.yml, web-ci.yml and secret-scan.yml.

web-ci needed it most: its paths filter is ['web/**', its own file], which is
correct but means a backend-only change never exercises it, and it was the one
workflow still absent from the Actions registry because nothing had triggered
it. The others re-registered on their own once #116's checks ran.

dependency-review stays pull_request-only — the action diffs a base against a
head, so a manual run has nothing to compare. keep-warm stays disabled_manually,
which is a deployment decision rather than a registration fault.

No paths filters on the manual triggers: pressing the button is an explicit
request to run the whole thing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant