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.
21 remaining items
ci: post CI reports to a Discussions thread per job (#2030)
ci: post Unit Tests push runs to Discussions (#2030)
ci: post the scheduled conda and Python-version reports to Discussions (
ci: post CI reports to a Discussions thread per job (#2030) (#2033)
ci: post Unit Tests push runs to Discussions (#2030)
ci: post the scheduled conda and Python-version reports to Discussions (
ci: post the scheduled conda and Python-version reports to Discussions (
ci: post Unit Tests push runs to Discussions (#2030) (#2036)
ci: post the scheduled conda and Python-version reports to Discussions (
JarryShaw commentedon Oct 22, 2026
Lint and Pages reporting is up in #2056. Three workflows need a call first:
mainruns all endsuccess. Recommended: the status isanalyze's result. The report lists open code-scanning alerts by severity, which needssecurity-events: readon the posting job only, and a rise in that count is awarning.main, a superseded or docs-only push skips every leg, which would post a "back to green" with nothing tested. Recommended: follow Unit Tests' rule: job conclusions plus annotations, with an empty by-design list. Post nothing whencurrentorchanges.codeis false.coverage-comment.ymlinto a sharedutil/script, rather than copy it into a third workflow, and use an empty by-design list.ci: post the Lint and GitHub Pages reports to Discussions (#2030)
JarryShaw commentedon Oct 22, 2026
go with your recommendations.