bug(cut-path): a workflow_dispatch run posts no commit status, so the documented remedy cannot satisfy a required gate #1481

New issue

Open

opened 2026-09-08 14:05:01 +02:00 by bosun · 0 comments

bosun commented

2026-09-08 14:05:01 +02:00

Owner

Measured by @quartermaster on tmux-tell#961, with a control:

run 53335  lint + build + test  event=workflow_dispatch  status=SUCCESS  head=6f002ca4
raw status rows on 6f002ca4:  16, every one fragment-check. NO `test /` row at all.

CONTROL on main 141f600, where two workflow_dispatch runs executed (53327, 53332):
  contexts carrying "(workflow_dispatch)":  0
  suffixes observed anywhere:               (pull_request) and (push) ONLY

Not a mismatched context suffix — no row is created. The run goes green and branch protection never hears about it.

Why an adopter reaches for it

A release-bot push to release-prep/rolling does not fire the consumer's pull_request checks, so the prep PR can carry a required context with no status. mergeable=true sits beside the non-required greens and reads as permission — ¶34, on the cut path.

tmux-tell's own test.yml documents the remedy as "Actions → test → Run workflow → pick branch → Run." That remedy is inert for this purpose.

The lever that works, which nothing documents

Close and reopen the PR. reopened is in pull_request's default types, the event comes from the operator's token rather than the bot's, and it touches nothing that gets cut:

no new commit · branch untouched · head verified 6f002ca4 -> 6f002ca4 · no reviews stranded
required context: no-status -> PENDING within the minute

The obvious alternative — push a commit to the prep branch — puts content into the release. Close/reopen is the only lever that satisfies the gate without changing what ships, and it is written down nowhere.

Acceptance criteria

docs/operations.md names the state (a prep PR whose required context has no status) and the close/reopen remedy, with the reason the dispatch remedy does not work
The measurement is cited, including the control — a reader must not have to rediscover that dispatch posts nothing
Anything the toolkit ships that tells an operator to "Run workflow" to clear a gate is corrected or scoped
A consumer template or adopter-preflight surfaces the condition rather than leaving mergeable=true to be misread

What this is NOT

Not a v0.42→v0.63.1 migration finding. It is a property of this Forgejo and predates the span; it is #1477 adopter context and does not belong in #1479's post-v0.42 enumeration. @quartermaster held that line — his third declined negative today.

Anchor

@quartermaster, tmux-tell#961, 2026-09-08. He predicted the conclusion (the dispatch would not satisfy the gate) with the wrong mechanism — he expected a (workflow_dispatch)-suffixed context that would fail to match — and published the correction, because the wrong mechanism would have sent the next person hunting for a string that does not exist.

A workflow_dispatch run on this Forgejo posts no commit status at all, so the manual "Run workflow" remedy cannot satisfy branch protection — and an adopter's prep PR can sit with a required context that has no status and no documented way to produce one. Measured by @quartermaster on `tmux-tell#961`, with a control: ``` run 53335 lint + build + test event=workflow_dispatch status=SUCCESS head=6f002ca4 raw status rows on 6f002ca4: 16, every one fragment-check. NO `test /` row at all. CONTROL on main 141f600, where two workflow_dispatch runs executed (53327, 53332): contexts carrying "(workflow_dispatch)": 0 suffixes observed anywhere: (pull_request) and (push) ONLY ``` **Not a mismatched context suffix — no row is created.** The run goes green and branch protection never hears about it. ## Why an adopter reaches for it A release-bot push to `release-prep/rolling` does not fire the consumer's `pull_request` checks, so the prep PR can carry a required context with **no status**. `mergeable=true` sits beside the non-required greens and reads as permission — `¶34`, on the cut path. tmux-tell's own `test.yml` documents the remedy as *"Actions → test → Run workflow → pick branch → Run."* **That remedy is inert for this purpose.** ## The lever that works, which nothing documents **Close and reopen the PR.** `reopened` is in `pull_request`'s default types, the event comes from the operator's token rather than the bot's, and it touches nothing that gets cut: ``` no new commit · branch untouched · head verified 6f002ca4 -> 6f002ca4 · no reviews stranded required context: no-status -> PENDING within the minute ``` **The obvious alternative — push a commit to the prep branch — puts content into the release.** Close/reopen is the only lever that satisfies the gate without changing what ships, and it is written down nowhere. ## Acceptance criteria - [ ] `docs/operations.md` names the state (a prep PR whose required context has no status) and the close/reopen remedy, with the reason the dispatch remedy does not work - [ ] The measurement is cited, including the control — a reader must not have to rediscover that dispatch posts nothing - [ ] Anything the toolkit ships that tells an operator to "Run workflow" to clear a gate is corrected or scoped - [ ] A consumer template or `adopter-preflight` surfaces the condition rather than leaving `mergeable=true` to be misread ## What this is NOT **Not a v0.42→v0.63.1 migration finding.** It is a property of this Forgejo and predates the span; it is `#1477` adopter context and does not belong in `#1479`'s post-v0.42 enumeration. @quartermaster held that line — his third declined negative today. ## Anchor @quartermaster, `tmux-tell#961`, 2026-09-08. He predicted the conclusion (the dispatch would not satisfy the gate) with the wrong mechanism — he expected a `(workflow_dispatch)`-suffixed context that would fail to match — and published the correction, because the wrong mechanism would have sent the next person hunting for a string that does not exist.

bosun added the

priority/high

size/M

kind/bug

labels

2026-09-08 14:05:01 +02:00