ci: scan main on push so code-scanning baseline stays current

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

Every open PR on this repo is stuck at mergeStateStatus: BLOCKED — including the promoted #271 (feat(create-issues-from-todos): support client-id), whose required CI - Required Checks is green and whose review threads are resolved.

Root cause, verified live:

• main's code-scanning baseline is frozen at 2025-07-17 (last zizmor analysis = commit b03c107, results_count: 9).
• All 9 open alerts sit on .github/workflows/reusable-workflow-ci-gitops-test.yaml — a file that no longer exists on main (1× zizmor/excessive-permissions, 8× zizmor/template-injection). They are phantom: the code that produced them was deleted months ago.
• The main branch has a code_scanning protection rule, so those 9 stale alerts are counted as a merge blocker on every PR, even when each PR's own required checks pass.

Why the baseline never refreshes:

zizmor:
  if: github.event_name != 'push'   # <-- never runs on push to main

The zizmor job (which holds security-events: write and uploads SARIF) was gated off for push events. But push-to-main is exactly the event that updates the default-branch code-scanning baseline. With it excluded, the baseline can never refresh and resolved findings can never auto-close — so the 2025-07-17 snapshot lingers indefinitely.

Fix

Swap the excluded event: run zizmor on pull_request (catch new findings) and on push to main (refresh the baseline so resolved findings auto-close), skipping only merge_group (the PR scan already ran; the queue ref makes a SARIF upload moot). One-line change to the job's if: plus a comment explaining why.

Once this is on main, the next push triggers a fresh zizmor analysis. Current code has 0 zizmor findings (the PR-event zizmor job passes), so the new baseline closes the 9 phantom alerts and the code_scanning blocker clears for all PRs.

⚠️ Maintainer: one-time unblock (chicken-and-egg)

This PR is itself BLOCKED by the same stale baseline, so it can't merge until the deadlock is broken once. Either:

1. Dismiss the 9 stale alerts (Security → Code scanning → filter by reusable-workflow-ci-gitops-test.yaml; they're on a deleted file). That immediately unblocks this PR, feat(create-issues-from-todos): support client-id, deprecate app-id #271, and every other open actions PR. Then merging this PR keeps the baseline fresh going forward so it can't recur; or
2. Admin-merge this PR once; the resulting push refreshes the baseline and closes the alerts.

Option 1 is preferred — it unblocks the whole lane right away, and this PR then prevents recurrence.

Validation

• actionlint .github/workflows/ci.yaml — clean for this change (the only output is two pre-existing code-quality permission-scope warnings on unrelated lines 326/740, a known actionlint-version lag on that newer scope).
• No behavior change to PR scanning; the only added behavior is the push-to-main baseline refresh.

Notes

• This corrects an earlier mis-diagnosis in maintenance notes that attributed feat(create-issues-from-todos): support client-id, deprecate app-id #271's block to a github-app finding on the token steps; the live code-scanning alerts show the real cause is the stale baseline above. Issue security: scope create-github-app-token tokens to least-privilege (zizmor github-app) #274 (least-privilege scoping of app-token steps) remains valid separate hardening but is not what blocks feat(create-issues-from-todos): support client-id, deprecate app-id #271.

[github-code-quality]

Code Coverage Overview

Languages: Go, C#

Go / code-coverage/test

The overall coverage remains at 50%, unchanged from the main branch.

C# / code-coverage/dotnet

The overall coverage remains at 100%, unchanged from the main branch.

---

_{Updated June 10, 2026 06:24 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}