fix: A release that released nothing is neither a success nor a failure #81

New issue

Closed

opened 2026-09-09 18:56:46 +00:00 by ahmad · 1 comment

ahmad commented

2026-09-09 18:56:46 +00:00

Owner

Context

A merge that warrants no release still sends a release notification, and that notification claims an outcome that did not happen.

ahmad/trip announced its last such run as ❌ failure. Its status expression still asks whether publish succeeded, and on a no-release run publish is skipped — so the expression falls through to failure. #72 fixed exactly this in six repositories; ahmad/trip and ahmad/portfolio were never converted and still carry the old expression.

The converted repositories are better but still wrong in a quieter way: they report ✅ success. Nothing succeeded — nothing ran. The reader cannot tell a release that worked from a merge that released nothing, which is the distinction they actually want at a glance.

notify-telegram documents skipped as a valid status but has no branch for it, so it lands on the catch-all warning icon — a normal, expected outcome dressed as something to look at.

Scope

In: a distinct, calm status for "nothing to release" in notify-telegram; the shared release template sending it; the two repositories that never adopted #72.
Out: whether a no-release run should notify at all (a separate question for the owner); the notify job's own resilience (#65).

Acceptance criteria

Given a run that released nothing, when the notification is sent, then its status is neither success nor failure, and its icon is distinct from both.
Given a release that published and deployed, then it still reports success exactly as now.
Given any job in the release genuinely failing, then it still reports failure — the new state must not swallow a real failure.
Given notify-telegram, then every status it documents has an explicit icon, and an unknown status still falls back rather than failing.
Given the shared template, then a consumer copying it gets all three outcomes without writing an expression of its own.
Given every repository that sends a release notification, then a follow-up issue exists for it, and ahmad/trip and ahmad/portfolio are fixed as part of this one because they are wrong today, not merely imprecise.

### Context A merge that warrants no release still sends a release notification, and that notification claims an outcome that did not happen. `ahmad/trip` announced its last such run as **❌ failure**. Its status expression still asks whether `publish` succeeded, and on a no-release run `publish` is skipped — so the expression falls through to `failure`. `#72` fixed exactly this in six repositories; `ahmad/trip` and `ahmad/portfolio` were never converted and still carry the old expression. The converted repositories are better but still wrong in a quieter way: they report **✅ success**. Nothing succeeded — nothing ran. The reader cannot tell a release that worked from a merge that released nothing, which is the distinction they actually want at a glance. `notify-telegram` documents `skipped` as a valid status but has no branch for it, so it lands on the catch-all warning icon — a normal, expected outcome dressed as something to look at. ### Scope - In: a distinct, calm status for "nothing to release" in `notify-telegram`; the shared release template sending it; the two repositories that never adopted `#72`. - Out: whether a no-release run should notify at all (a separate question for the owner); the notify job's own resilience (`#65`). ### Acceptance criteria - [ ] Given a run that released nothing, when the notification is sent, then its status is neither success nor failure, and its icon is distinct from both. - [ ] Given a release that published and deployed, then it still reports success exactly as now. - [ ] Given any job in the release genuinely failing, then it still reports failure — the new state must not swallow a real failure. - [ ] Given `notify-telegram`, then every status it documents has an explicit icon, and an unknown status still falls back rather than failing. - [ ] Given the shared template, then a consumer copying it gets all three outcomes without writing an expression of its own. - [ ] Given every repository that sends a release notification, then a follow-up issue exists for it, and `ahmad/trip` and `ahmad/portfolio` are fixed as part of this one because they are wrong today, not merely imprecise.

ahmad added the

labels

2026-09-09 18:56:55 +00:00

ahmad self-assigned this

2026-09-09 18:56:56 +00:00

ahmad referenced this issue from a pull request that will close it,

2026-09-09 18:58:29 +00:00

fix: Report a release that released nothing as skipped #82

ahmad

2026-09-09 18:58:29 +00:00

closed this issue
added
state/in-review
and removed
state/in-progress
labels