[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• ci — changes to CI configuration files and scripts

---

Description of your pull request and other information

The CodeQL part of #2030, per the owner's rulings there and on this PR: post the report whenever something is flagged.

• codeql-analysis.yml: gains a discussion job after analyze that posts to codeql-analysis: CodeQL report. Scheduled runs post every run. Push runs follow the push rule, and pull requests never post. The job alone holds discussions: write and security-events: read; top-level permissions: {} is unchanged. Everything is continue-on-error, so reporting never turns CodeQL red.
• New util/codeql_report.py: lists open CodeQL alerts by severity, through the code-scanning alerts API, and outputs status.
  • warning: analyze succeeded and an alert is open.
  • success: analyze succeeded and nothing is open.
  • Anything else: analyze's own result stands.
  • A failed read: gives one ::warning. The report says the alerts are unavailable, and the status stays analyze's result, so a failed read never claims success.
• What gets posted: every run with open alerts posts. The first run back at zero posts once, then the thread goes quiet.
• util/discussion_report.py: unchanged from main.
• Tests: the new tests/project/test_codeql_report_2030.py (16 tests) fails on main and passes here. It runs each status case end to end through the real discussion_report.py. The discussion, cron, push-report, helper and Lint-pin tests plus the docs-claim tests all pass. actionlint 1.7.12 reports only the finding Lint already ignores.

[JarryShaw]

What about we post the CodeQL report summary every time if there's something being flagged out?

[JarryShaw]

GOOD TO GO at 08ade35cc (Sonnet cross-review). The push-run "post on any count change" question is still open for the owner.

• Permissions and triggers: only discussion holds discussions: write and security-events: read, and analyze and the top-level permissions: {} are unchanged. The job never runs on pull_request, and continue-on-error is set on the job and both steps, so a reporting failure can't turn CodeQL red.
• codeql_report.py: the endpoint and its parameters match the docs. The reviewer tested the pagination decoder on concatenated arrays, a single array, empty input and []\n[]. The severity falls back from security_severity_level to severity. A failed read gives one ::warning and exits 0.
• --count: behaviour without it is unchanged. A human reply quoting a count marker is ignored, because both markers must be present.
• Shell: the empty counted array expansion is safe under the runner's bash.
• Tests: 200 passed across the new file and the discussion, cron, push-report, helper, Lint-pin and docs-claim tests.

[JarryShaw]

Sorry, my verdict above went up over your comment. Recorded: post the CodeQL report whenever something is flagged. The rule becomes:

• Warning: any open alert on a successful analyze is warning, so every push and scheduled run with open alerts posts, alerts listed by severity.
• Back to green: once the count returns to zero, a single recovery post goes out, then silence.
• Failure: a failed analyze posts as before.

That makes the rise/fall comparison and the --count marker unnecessary, so I'll take them out and leave discussion_report.py as it is on main. The rework is in progress.

[JarryShaw]

GOOD TO GO at df3e5b4f8 (Sonnet delta re-review).

• util/discussion_report.py: byte-identical to main, with no --count or marker leftovers anywhere.
• Status: analyze's result stands unless it succeeded. Then an open alert gives warning and none gives success. A failed read keeps analyze's result plus one ::warning and an "unavailable" note.
• Empty report output: ${REPORT_STATUS:-$ANALYZE_RESULT} falls back when the report step leaves it empty, and a test covers that.
• End-to-end tests: I checked these myself. TestEndToEnd copies the real discussion_report.py, codeql_report.py and _actions.py and runs them against a stand-in GitHub, so the push-rule outcomes are measured, not mocked.

170 passed across the CodeQL, discussion, cron, helper, Lint-pin and docs-claim tests.