A skipped deploy is announced as a failure in six repositories

ahmad commented

2026-09-09 09:19:41 +00:00

Owner

Context

notify-telegram@v3 documents its status input as "success, failure,
cancelled or skipped", and its script gives each of the four its own icon
— cancelled renders ⚪, anything unrecognised ⚠️. needs.<job>.result
yields exactly those same four values, so passing it straight through is
the contract the action already declares.

Six repositories instead collapse it in deploy.yml:

status: ${{ needs.deploy.result == 'success' && 'success' || 'failure' }}

Bayan/bayan-web, Bayan/kidpoints, ahmad/namey, suhba/khitta,
suhba/suhba-docs, suhba/suhba-web. Surveyed 2026-09-09 through the
contents API across every workflow file on the server, parsing each
notify job rather than grepping.

In all six the deploy job is guarded by
if: vars.ENABLE_VPS_DEPLOY == 'true', so its result can be skipped;
and any run can be cancelled. Both are reported as failure. The
message says a deploy failed when nothing was deployed at all.

That matters most in the case it is most likely to fire. ENABLE_VPS_DEPLOY
is set to true everywhere today, so the way it becomes skipped is
somebody deliberately disabling deploys — usually mid-incident. A false
failure alert is least welcome exactly then, and it trains the reader to
discount the channel.

ahmad/expiro, ahmad/imamah, ahmad/larda, ahmad/portfolio and
ahmad/trip already pass the result through in deploy.yml, so the
correct form is on the fleet and is the majority. Bayan/stem#15 added a
notify job that does the same and carries the reasoning.

The pr.yml notify jobs in ahmad/expiro, ahmad/larda and
ahmad/portfolio use the same collapsing expression, but nothing they
depend on is guarded, so a skipped result is not reachable there the
same way. Out of scope below; worth a look only if those jobs gain a
conditional dependency.

Scope

In: replacing the collapsing expression with
status: ${{ needs.deploy.result }} in the deploy.yml of the six
repositories listed above; one pull request per repository.
In: a line of comment saying why the result is passed through, since
the bare form invites someone to "fix" it back into a conditional.
Out: the pr.yml notify jobs, where no dependency is guarded.
Out: the details text, the title, or anything else about those
messages.
Out: notify-telegram itself, which already handles all four values.

Acceptance criteria

Given each of the six repositories, when deploy.yml's notify step
is read, then status is the deploy job's result unmapped.
Given a deploy that is skipped because ENABLE_VPS_DEPLOY is not
true, when the notification is sent, then it reports skipped
and not failure.
Given a cancelled run, when the notification is sent, then it
reports cancelled.
Given a genuinely failed deploy, when the notification is sent,
then it still reports failure.

### Context `notify-telegram@v3` documents its `status` input as "success, failure, cancelled or skipped", and its script gives each of the four its own icon — `cancelled` renders `⚪`, anything unrecognised `⚠️`. `needs.<job>.result` yields exactly those same four values, so passing it straight through is the contract the action already declares. Six repositories instead collapse it in `deploy.yml`: ```yaml status: ${{ needs.deploy.result == 'success' && 'success' || 'failure' }} ``` `Bayan/bayan-web`, `Bayan/kidpoints`, `ahmad/namey`, `suhba/khitta`, `suhba/suhba-docs`, `suhba/suhba-web`. Surveyed 2026-09-09 through the contents API across every workflow file on the server, parsing each `notify` job rather than grepping. In all six the `deploy` job is guarded by `if: vars.ENABLE_VPS_DEPLOY == 'true'`, so its result can be `skipped`; and any run can be `cancelled`. Both are reported as **failure**. The message says a deploy failed when nothing was deployed at all. That matters most in the case it is most likely to fire. `ENABLE_VPS_DEPLOY` is set to `true` everywhere today, so the way it becomes `skipped` is somebody deliberately disabling deploys — usually mid-incident. A false failure alert is least welcome exactly then, and it trains the reader to discount the channel. `ahmad/expiro`, `ahmad/imamah`, `ahmad/larda`, `ahmad/portfolio` and `ahmad/trip` already pass the result through in `deploy.yml`, so the correct form is on the fleet and is the majority. `Bayan/stem#15` added a notify job that does the same and carries the reasoning. The `pr.yml` notify jobs in `ahmad/expiro`, `ahmad/larda` and `ahmad/portfolio` use the same collapsing expression, but nothing they depend on is guarded, so a `skipped` result is not reachable there the same way. Out of scope below; worth a look only if those jobs gain a conditional dependency. ### Scope - In: replacing the collapsing expression with `status: ${{ needs.deploy.result }}` in the `deploy.yml` of the six repositories listed above; one pull request per repository. - In: a line of comment saying why the result is passed through, since the bare form invites someone to "fix" it back into a conditional. - Out: the `pr.yml` notify jobs, where no dependency is guarded. - Out: the `details` text, the title, or anything else about those messages. - Out: `notify-telegram` itself, which already handles all four values. ### Acceptance criteria - [ ] Given each of the six repositories, when `deploy.yml`'s notify step is read, then `status` is the deploy job's result unmapped. - [ ] Given a deploy that is skipped because `ENABLE_VPS_DEPLOY` is not `true`, when the notification is sent, then it reports `skipped` and not `failure`. - [ ] Given a cancelled run, when the notification is sent, then it reports `cancelled`. - [ ] Given a genuinely failed deploy, when the notification is sent, then it still reports `failure`.

ahmad added the

labels

2026-09-09 09:19:42 +00:00

ahmad self-assigned this

2026-09-09 09:44:01 +00:00

ahmad added

state/in-progress

and removed

state/ready

labels

2026-09-09 09:44:02 +00:00

ahmad commented

2026-09-09 09:44:37 +00:00

Author

Owner

Taking this. One line plus a comment in each of the six deploy.yml
files; one pull request per repository.

Something the survey missed, and it sharpens the bug rather than
softening it. All six already print the real result in details:
image <v> by <actor> — ${{ needs.deploy.result }}. So a skipped deploy
today sends a message whose headline reads ❌ … — failure and whose very
next line reads — skipped. It does not merely misreport; it contradicts
itself, and the wrong half is the half carrying the icon.

Change. status: ${{ needs.deploy.result }}, with a short comment
saying the four values the context yields are exactly the four the action
documents — otherwise the next reader sees a bare expression where the
neighbours have a conditional and "fixes" it back.

Out of scope, deliberately. Once status carries the result, the
details line repeats it. That redundancy is harmless and the issue
scopes details out, so I am leaving it rather than quietly rewording
six messages.

Verification, and its limit. I can check that the rendered expression
yields each of the four values and that nothing else in the job moved.
What I cannot do from a pull request is dispatch a deploy with
ENABLE_VPS_DEPLOY unset and read the resulting Telegram message — the
acceptance criteria are written as observations of a sent notification,
and I will say on each PR which half is verified rather than tick them
all.

Taking this. One line plus a comment in each of the six `deploy.yml` files; one pull request per repository. **Something the survey missed, and it sharpens the bug rather than softening it.** All six already print the real result in `details`: `image <v> by <actor> — ${{ needs.deploy.result }}`. So a skipped deploy today sends a message whose headline reads `❌ … — failure` and whose very next line reads `— skipped`. It does not merely misreport; it contradicts itself, and the wrong half is the half carrying the icon. **Change.** `status: ${{ needs.deploy.result }}`, with a short comment saying the four values the context yields are exactly the four the action documents — otherwise the next reader sees a bare expression where the neighbours have a conditional and "fixes" it back. **Out of scope, deliberately.** Once `status` carries the result, the `details` line repeats it. That redundancy is harmless and the issue scopes `details` out, so I am leaving it rather than quietly rewording six messages. **Verification, and its limit.** I can check that the rendered expression yields each of the four values and that nothing else in the job moved. What I cannot do from a pull request is dispatch a deploy with `ENABLE_VPS_DEPLOY` unset and read the resulting Telegram message — the acceptance criteria are written as observations of a sent notification, and I will say on each PR which half is verified rather than tick them all.

ahmad referenced this issue from a commit

2026-09-09 09:46:00 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:46:03 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:46:06 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:46:11 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:46:16 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:46:19 +00:00

fix: Report a skipped deploy as skipped

ahmad added

state/in-review

and removed

state/in-progress

labels

2026-09-09 09:46:36 +00:00

ahmad referenced this issue from a commit

2026-09-09 09:49:17 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 09:49:20 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue

2026-09-09 09:49:40 +00:00

chore: Carry the non-blocking notify fetch to the eight consumers #68

ahmad referenced this issue from a commit

2026-09-09 11:14:05 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 11:14:07 +00:00

fix: Report a skipped deploy as skipped

ahmad referenced this issue from a commit

2026-09-09 11:14:10 +00:00

fix: Report a skipped deploy as skipped

ahmad commented

2026-09-09 12:45:51 +00:00

Author

Owner

Done. All six repositories merged.

Repository	PR	Merge
`Bayan/bayan-web`	Bayan/bayan-web#34	`e9e5f76`
`Bayan/kidpoints`	Bayan/kidpoints#213	`5c96048`
`ahmad/namey`	ahmad/namey#78	`f3ccd8c`
`suhba/khitta`	suhba/khitta#57	`9400dfc`
`suhba/suhba-docs`	suhba/suhba-docs#15	`72db22e`
`suhba/suhba-web`	suhba/suhba-web#44	`099f313`

Every deploy.yml notify job now passes needs.deploy.result straight to
notify-telegram instead of mapping it to success-or-failure. A deploy
skipped because ENABLE_VPS_DEPLOY is not true, and a cancelled run,
are reported as themselves rather than as failures.

One thing found while implementing that the issue had not noticed, and
it makes the case stronger rather than weaker: all six already printed the
true result in details. So a skipped deploy sent a message whose headline
read ❌ … — failure and whose next line read — skipped. It was not
merely misreporting; it contradicted itself, and the half carrying the
icon was the wrong half.

Each pull request was checked mechanically rather than by reading the
diff: the workflow re-parsed on the head and compared against main,
confirming the deploy job, the job set, the notify job's own keys, its
step count and every other notify-telegram input were byte-identical. A
one-line diff is exactly where a stray second edit hides.

Three acceptance criteria remain unobserved, and no pull request could
observe them. That a skipped deploy now reports skipped, a cancelled
one cancelled, and a genuine failure still failure are claims about
messages that were sent. What supports them is a contract, stated exactly:
needs.<job>.result yields one of success, failure, cancelled or skipped;
notify-telegram's action.yml documents status as that same set and
branches on all four by name, giving cancelled its own icon. The first
manual deploy in any of these six is where to confirm the message reads as
intended.

Out of scope and still true: the pr.yml notify jobs in ahmad/expiro,
ahmad/larda and ahmad/portfolio use the same collapsing expression.
Nothing they depend on is guarded, so skipped is not reachable there the
same way — worth revisiting only if one of those jobs gains a conditional
dependency.

**Done. All six repositories merged.** | Repository | PR | Merge | |---|---|---| | `Bayan/bayan-web` | Bayan/bayan-web#34 | `e9e5f76` | | `Bayan/kidpoints` | Bayan/kidpoints#213 | `5c96048` | | `ahmad/namey` | ahmad/namey#78 | `f3ccd8c` | | `suhba/khitta` | suhba/khitta#57 | `9400dfc` | | `suhba/suhba-docs` | suhba/suhba-docs#15 | `72db22e` | | `suhba/suhba-web` | suhba/suhba-web#44 | `099f313` | Every `deploy.yml` notify job now passes `needs.deploy.result` straight to `notify-telegram` instead of mapping it to success-or-failure. A deploy skipped because `ENABLE_VPS_DEPLOY` is not `true`, and a cancelled run, are reported as themselves rather than as failures. **One thing found while implementing that the issue had not noticed**, and it makes the case stronger rather than weaker: all six already printed the true result in `details`. So a skipped deploy sent a message whose headline read `❌ … — failure` and whose next line read `— skipped`. It was not merely misreporting; it contradicted itself, and the half carrying the icon was the wrong half. Each pull request was checked mechanically rather than by reading the diff: the workflow re-parsed on the head and compared against `main`, confirming the `deploy` job, the job set, the notify job's own keys, its step count and every other `notify-telegram` input were byte-identical. A one-line diff is exactly where a stray second edit hides. **Three acceptance criteria remain unobserved, and no pull request could observe them.** That a skipped deploy now reports `skipped`, a cancelled one `cancelled`, and a genuine failure still `failure` are claims about messages that were sent. What supports them is a contract, stated exactly: `needs.<job>.result` yields one of success, failure, cancelled or skipped; `notify-telegram`'s `action.yml` documents `status` as that same set and branches on all four by name, giving `cancelled` its own icon. The first manual deploy in any of these six is where to confirm the message reads as intended. Out of scope and still true: the `pr.yml` notify jobs in `ahmad/expiro`, `ahmad/larda` and `ahmad/portfolio` use the same collapsing expression. Nothing they depend on is guarded, so `skipped` is not reachable there the same way — worth revisiting only if one of those jobs gains a conditional dependency.

ahmad

2026-09-09 12:45:52 +00:00

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

ahmad referenced this issue

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

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

Rows
Columns

A skipped deploy is announced as a failure in six repositories #72

Context

Scope

Acceptance criteria