Opening this as a question rather than a fix, because the answer is a call about notification channels and it touches .github/workflows/. Happy to implement whichever shape you pick, or to drop it.
The observation
Acceptance (nightly) has run 50 times since 31 July. 49 failed, 1 was cancelled, none passed. The last 20 runs are all failure.
Nothing in the repository connects that to a person. No workflow opens an issue, and no workflow sends a failure anywhere outside its own run log. A red nightly is indistinguishable from a green one unless somebody opens the Actions tab and looks.
Two things that cost real time as a result:
The parts already exist
This is not a missing capability, it is an unconnected one.
release.yml posts to Discord through DISCORD_RELEASES_WEBHOOK, documented in docs/project-setup.md §6, and skips with a warning when the secret is absent so a fork is unaffected. That posture is exactly what a CI notification wants.sync-labels.yml already runs with issues: write, so the permission shape has a precedent too.ci.yml has good failure handling (report:test-failures annotations, the size-overshoot artifact) but all of it lives inside the run, for a reader who is already there.
acceptance.yml has none of the three.
What I would suggest, and the question
An if: failure() step on the nightly that raises the failure somewhere a human passes. The scoreboard line the suite already prints is enough payload:
21 passed, 2 failed, 1 skipped
✗ 22 Seeds extensions roundtrip [...]
✗ 42 One-line self-host [...]
Three shapes, and I do not want to guess which you want:
- One tracking issue, opened once and updated. Survives a closed Actions tab and carries the history. Needs
issues: write and dedupe logic, otherwise 49 nights is 49 issues.
- A Discord webhook, mirroring the release announcement. Cheapest to write, matches where you already read things, leaves no durable record.
- Neither. If the nightly is meant to be a thing you check by hand when you care, that is a valid answer and I will close this.
Whichever you pick, one detail matters more than the channel: it should fire on a change of state, not on every red night, or it becomes noise within a week and gets muted. Red-to-green is worth saying too.
If you want shape 1 or 2, say which and I will open the PR.
Opening this as a question rather than a fix, because the answer is a call about notification channels and it touches
.github/workflows/. Happy to implement whichever shape you pick, or to drop it.The observation
Acceptance (nightly)has run 50 times since 31 July. 49 failed, 1 was cancelled, none passed. The last 20 runs are allfailure.Nothing in the repository connects that to a person. No workflow opens an issue, and no workflow sends a failure anywhere outside its own run log. A red nightly is indistinguishable from a green one unless somebody opens the Actions tab and looks.
Two things that cost real time as a result:
21 passed, 2 failed, 1 skipped, identical on 15, 16 and 17 September. One of the two failures is a regression from 7 September (acceptance scenario 22 still expects the 201 for an unknown seedId that #1234 turned into a 404 #1266) that had been sitting inmainsince then. The nightly had been printing the evidence for three nights.The parts already exist
This is not a missing capability, it is an unconnected one.
release.ymlposts to Discord throughDISCORD_RELEASES_WEBHOOK, documented indocs/project-setup.md§6, and skips with a warning when the secret is absent so a fork is unaffected. That posture is exactly what a CI notification wants.sync-labels.ymlalready runs withissues: write, so the permission shape has a precedent too.ci.ymlhas good failure handling (report:test-failuresannotations, the size-overshoot artifact) but all of it lives inside the run, for a reader who is already there.acceptance.ymlhas none of the three.What I would suggest, and the question
An
if: failure()step on the nightly that raises the failure somewhere a human passes. The scoreboard line the suite already prints is enough payload:Three shapes, and I do not want to guess which you want:
issues: writeand dedupe logic, otherwise 49 nights is 49 issues.Whichever you pick, one detail matters more than the channel: it should fire on a change of state, not on every red night, or it becomes noise within a week and gets muted. Red-to-green is worth saying too.
If you want shape 1 or 2, say which and I will open the PR.