Repository navigation
ci: deliver scheduled-run reports somewhere that notifies #2030
Description
Is your feature request related to a problem? Please describe.
Scheduled runs (ci-timing, cron-vendor, cron-conda, cron-python-versions, codeql-analysis, ...) have no PR to comment on. Their reports reach nobody: a step summary sends no notification, and ci-timing only signals by failing, which GitHub emails to whoever last edited its cron line.
Describe the solution you'd like
Recommended: Discussions (already enabled).
- Add a "CI reports" announcement-type category, with one thread per workflow.
- A separate job with
discussions: writecomments only when the report changed or crossed a threshold. It usesgh api graphqlandGITHUB_TOKEN, with no third-party action. - You get email through normal GitHub notifications if you watch the category.
- It stays off the issue board, so the board-clear goal and state labels are untouched.
- Start with
ci-timingandcron-vendor.
Describe alternatives you've considered
- A rolling report issue per workflow (
issues: write): this works, but it sits open forever and needs a carve-out from the sweeps and state labels. - SMTP email (
dawidd6/action-send-mailplus secrets): this runs third-party code beside a secret, which is what ci: harden the workflows (deploy-key step, action pinning, unused secrets, permissions) #1968 removed. Not recommended. - Keep failing-to-email only: this says something fired, not what the report said.
Additional context
The reusable unit-tests.yml stays without write permissions, since its callers grant contents: read. Decision needed: Discussions, a rolling issue, or neither; and which workflows report first.
Activity
JarryShaw commentedon Oct 22, 2026
Go with Discussions. I think we create one new discussion to hold all these reports. and for each thread, it holds one job's reports - each job will just add a comment to the same thread instead of creating new threads.
JarryShaw commentedon Oct 22, 2026
Starts with the two but will cover all with this issue.
JarryShaw commentedon Oct 22, 2026
Taking Discussions, as I read your two comments: one category holds all the reports, with one thread per job. Each run adds a comment to its job's thread rather than opening a new one.
ci-timingandcron-vendorgo first, then every other scheduled workflow, all under this issue.util/discussion_report.pyfinds the job's thread by title and creates it only on first use, so no ids are hard-coded. It then adds one comment, but only when the report changed or crossed a threshold. It usesgh api graphqlandGITHUB_TOKENin a job holding onlydiscussions: write.ci-timingandcron-vendor, stacked on ci: fix shellcheck findings and trim workflow comments (#1967) #2023 since it edits both files. The remaining workflows follow in later PRs.Needs you: the API cannot create a category (GraphQL has no mutation for it), so it has to be made in Settings → Discussions. My recommendation: a category called CI reports, in the Announcement format so only maintainers and the bot can start threads. The script reads the category name from its input and the tests stub the API, so the work starts now.
JarryShaw commentedon Oct 22, 2026
Category created.
JarryShaw commentedon Oct 22, 2026
Confirmed: the API now lists
CI reports(slugci-reports). The first PR uses that name.JarryShaw commentedon Oct 22, 2026
I think this applies not only to scheduled ones but also those run on branches - anything that generates a report but cannot post to a PR's comment should go there.
JarryShaw commentedon Oct 22, 2026
Scope widened, as I read it: every report that has no PR to comment on goes to its job's thread, whether it comes from a scheduled run or a branch push. A report from a PR run keeps commenting on the PR. Plan:
util/discussion_report.pyplusci-timingandcron-vendor.Unit Tests.unit-tests.ymlis reusable and must keepcontents: read, so posting goes throughcoverage-comment.yml'sworkflow_runrelay, which today only handlespull_requestruns. It gains a branch for other events that posts to the thread instead of a PR.experimental.yml(its non-blocking warnings),python-compatibility.yml,lint.ymland the remaining crons, one workflow each.Needs you: how often a push run posts. Pushes to
mainland several times an hour during a merge wave.My recommendation: post only when the report differs from the last one in the thread, or when a non-blocking leg warned or failed, and never for an unchanged green run. The alternative is every run. I'm building the recommended behaviour now; it's one flag to change if you'd rather have every run.
38 remaining items
JarryShaw commentedon Oct 22, 2026
Next addition: the Unit Tests reports in #2057 will also carry each job's step summary.
Python 3.15job, the check run'soutput.summaryisnull. So every step that writes$GITHUB_STEP_SUMMARYinunit-tests.ymlwill also copy its block into a per-job file, and each job uploads that file as a small artifactif: always().<details>section per job under the status line. It trims to fit the comment size limit and links the run when it cuts.Retrying … after connectionline fromProject tests, which is network noise. Pip retry lines stop counting as warnings.When: after #2053, which edits both
unit-tests.ymlandcoverage-comment.yml. It goes in the same PR as the shared reporter for Experimental and Compat, so those get summaries too.JarryShaw commentedon Oct 22, 2026
Owner ruling, paraphrased: warning and error lines on a successful run don't earn a post. They matter only when the run failed, or on legs whose steps are forced to succeed.
New push-run rule for Unit Tests, and later Experimental and Compat, in the shared-reporter PR after #2053:
(KTLO)legs, and the(experimental)legs, which are forced green the same way.Retrying … after connectionlines are ignored on every leg.ci: post the CodeQL report to Discussions (#2030)
ci: post the Lint and GitHub Pages reports to Discussions (#2030) (#2056
ci: post the CodeQL report to Discussions (#2030) (#2058)
ci: report Experimental Tests and Python Compatibility to Discussions…
ci: report Experimental Tests and Python Compatibility to Discussions…
JarryShaw commentedon Oct 23, 2026
Done. Every piece has merged:
CI reportsDiscussions category.util/check_suite_report.py, step summaries carried through artifacts, the push rule (a passing job's annotations don't trigger a post), and pip retries dropped from the warning count.Two things are still unverified until a live post: the artifact layout from
gh run download, and whether a@in a summary renders as a mention. I'll check the first real reports and open a fix if either goes wrong.ci: put two trivial util/ steps back inline (#1967)
ci: put two trivial util/ steps back inline (#1967) (#2092)