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

bosun commented

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

Member

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 — DONE @ #1572 (landed e830e94, reviewed as e830e94)
The measurement is cited, including the control — a reader must not have to rediscover that dispatch posts nothing — DONE @ #1572 (landed e830e94, reviewed as e830e94)
Anything the toolkit ships that tells an operator to "Run workflow" to clear a gate is corrected or scoped — PARTLY @ #1572: docs/operations.md corrected. Still open: .forgejo/workflows/go-ci.yml:17-19,29 gives the same dispatch advice for a required check (workflow YAML, left for Alex).
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 - [x] `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 — DONE @ #1572 (landed e830e94, reviewed as e830e94) - [x] The measurement is cited, including the control — a reader must not have to rediscover that dispatch posts nothing — DONE @ #1572 (landed e830e94, reviewed as e830e94) - [ ] Anything the toolkit ships that tells an operator to "Run workflow" to clear a gate is corrected or scoped — PARTLY @ #1572: `docs/operations.md` corrected. Still open: `.forgejo/workflows/go-ci.yml:17-19,29` gives the same dispatch advice for a required check (workflow YAML, left for Alex). - [ ] 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

labels

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

claude self-assigned this

2026-10-07 01:55:22 +02:00

claude commented

2026-10-07 01:55:25 +02:00

Member

Claimed by the rt-bugfix-loop (implementer session) for the docs ACs 1-3 only; PR to follow. AC 4 (surfacing the condition in adopter-preflight or a consumer template) stays open: whether a release-bot push fires pull_request checks is contested (docs/operations.md says it does, this issue's tmux-tell PR 961 measured no status), and the state appears at cut time, where adopter-preflight cannot see it.

Claimed by the rt-bugfix-loop (implementer session) for the docs ACs 1-3 only; PR to follow. AC 4 (surfacing the condition in `adopter-preflight` or a consumer template) stays open: whether a release-bot push fires `pull_request` checks is contested (`docs/operations.md` says it does, this issue's tmux-tell PR 961 measured no status), and the state appears at cut time, where `adopter-preflight` cannot see it.

claude referenced this issue from a commit

2026-10-07 01:58:01 +02:00

docs(operations): a rolling PR's missing required check is cleared by close and reopen, not dispatch

claude referenced this issue

2026-10-07 01:58:04 +02:00

docs(operations): a rolling PR's missing required check is cleared by close and reopen, not dispatch #1572

claude referenced this issue from a commit

2026-10-07 02:02:12 +02:00

docs(operations): correct the release-bot caveat to the forge record

claude commented

2026-10-07 11:37:29 +02:00

Member

rt-bugfix-loop: the docs part landed. Keep this open: two ACs remain, both outside the loop.

Landed: e830e94 on main by fast-forward, PR #1572, approved by @surveyor at that head (review 7300). CI at that head: 30/30 success. ACs 1 and 2 are ticked.
AC 3, partly done: docs/operations.md is corrected. .forgejo/workflows/go-ci.yml:17-19 and :29 still tell operators to dispatch when a bot push does not trigger CI, and go-ci / lint + build + test (pull_request) is required on main. That is workflow YAML, which the loop does not edit. Found in review 7299.
AC 4, open: needs a live run first. On tmux-tell PR 961, release-bot's opening push ran test, but its later force-push (re-preparing as v0.39.2) ran fragment-check and not test or manifest-check. Why is not established, and the warning's wording depends on it. Where the warning belongs is also open: adopter-preflight runs before any cut, and rt prep is the cut path.

Unassigning the loop.

rt-bugfix-loop: the docs part landed. **Keep this open:** two ACs remain, both outside the loop. - **Landed:** `e830e94` on main by fast-forward, PR #1572, approved by @surveyor at that head (review 7300). CI at that head: 30/30 success. ACs 1 and 2 are ticked. - **AC 3, partly done:** `docs/operations.md` is corrected. `.forgejo/workflows/go-ci.yml:17-19` and `:29` still tell operators to dispatch when a bot push does not trigger CI, and `go-ci / lint + build + test (pull_request)` is required on main. That is workflow YAML, which the loop does not edit. Found in review 7299. - **AC 4, open:** needs a live run first. On tmux-tell PR 961, release-bot's opening push ran `test`, but its later force-push (re-preparing as v0.39.2) ran `fragment-check` and not `test` or `manifest-check`. Why is not established, and the warning's wording depends on it. Where the warning belongs is also open: `adopter-preflight` runs before any cut, and `rt prep` is the cut path. Unassigning the loop.

claude removed their assignment

2026-10-07 11:37:29 +02:00

quartermaster added this to the Set L - v0.68.0 cut and Storey adoption milestone

2026-10-13 11:02:29 +02:00

Rows
Columns

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

Why an adopter reaches for it

The lever that works, which nothing documents

Acceptance criteria

What this is NOT

Anchor