chore(workflows): self-bootstrap release.yml @v0.10.4-rc.1 (#139 cancel-noise fix dogfood) #146

Merged

quartermaster merged 1 commit from i/self-bootstrap-v0.10.4-rc.1 into main

2026-06-27 00:10:42 +02:00

quartermaster commented

2026-06-27 00:09:05 +02:00

Owner

Self-bootstrap re-pin — in-cycle per discipline (10th in chain)

Tagged v0.10.4-rc.1 at #144's merge SHA — closes #139 with the two-pronged paths-ignore + re-order fix.

- uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.10.3-rc.1
+ uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.10.4-rc.1
- toolkit_ref:   v0.10.3-rc.1
+ toolkit_ref:   v0.10.4-rc.1

What v0.10.4-rc.1 carries

Surface	Detail
`.forgejo/workflows/release.yml`	`paths-ignore: ['.release-toolkit-manifest.json']` on push trigger
`.forgejo/workflows/_release.yml`	Stale-rolling-PR cleanup re-ordered to BEFORE the manifest mechanism (defense-in-depth)
`tests/workflows.bats`	+1 regression guard for paths-ignore
`docs/integration.md`	Quick-start template shows paths-ignore + manifest_path customization caveat

Empirical close criteria (per Surveyor 8b46)

The next path-α cut on toolkit-self provides the validation:

Observable	Means
Manifest direct-push does NOT fire a new workflow run	paths-ignore works on gitea-1.22 → #139 actually closed
Cut workflow tasks all report SUCCESS (no cancellation)	The race is eliminated

Surveyor's important precision: the dispatch-at-historical-ref pattern from #140 close does NOT apply here — that was for re-running existing tasks; paths-ignore is a push-trigger filter that workflow_dispatch bypasses. The empirical close requires a real manifest-only push, which is exactly what the next path-α cut produces.

Refs

Closes: nothing directly
Tag: v0.10.4-rc.1 at #144's merge SHA
#139 fix PR: #144
Surveyor 8b46 review chain: paths-ignore validation precision + dispatch-doesn't-apply clarification
In-cycle re-pin discipline: 10th in the embodied chain (#82/#91/#95/#100/#118/#123/#127/#133/#138/#143)

## Self-bootstrap re-pin — in-cycle per discipline (10th in chain) Tagged `v0.10.4-rc.1` at #144's merge SHA — closes #139 with the two-pronged paths-ignore + re-order fix. ```diff - uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.10.3-rc.1 + uses: frankenbit/release-toolkit/.forgejo/workflows/_release.yml@v0.10.4-rc.1 - toolkit_ref: v0.10.3-rc.1 + toolkit_ref: v0.10.4-rc.1 ``` ## What v0.10.4-rc.1 carries | Surface | Detail | |---|---| | `.forgejo/workflows/release.yml` | `paths-ignore: ['.release-toolkit-manifest.json']` on push trigger | | `.forgejo/workflows/_release.yml` | Stale-rolling-PR cleanup re-ordered to BEFORE the manifest mechanism (defense-in-depth) | | `tests/workflows.bats` | +1 regression guard for paths-ignore | | `docs/integration.md` | Quick-start template shows paths-ignore + manifest_path customization caveat | ## Empirical close criteria (per Surveyor 8b46) The next path-α cut on toolkit-self provides the validation: | Observable | Means | |---|---| | Manifest direct-push does NOT fire a new workflow run | paths-ignore works on gitea-1.22 → #139 actually closed | | Cut workflow tasks all report SUCCESS (no cancellation) | The race is eliminated | Surveyor's important precision: **the dispatch-at-historical-ref pattern from #140 close does NOT apply here** — that was for re-running existing tasks; paths-ignore is a push-trigger filter that workflow_dispatch bypasses. The empirical close requires a real manifest-only push, which is exactly what the next path-α cut produces. ## Refs - **Closes**: nothing directly - **Tag**: `v0.10.4-rc.1` at #144's merge SHA - **#139 fix PR**: [#144](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/144) - **Surveyor 8b46 review chain**: paths-ignore validation precision + dispatch-doesn't-apply clarification - **In-cycle re-pin discipline**: 10th in the embodied chain (#82/#91/#95/#100/#118/#123/#127/#133/#138/#143)

quartermaster added 1 commit

2026-06-27 00:09:05 +02:00

chore(workflows): self-bootstrap release.yml @v0.10.4-rc.1 (#139 cancel-noise fix dogfood)

manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s

Details

manifest-check / check (pull_request) Successful in 0s

Details

release / decide + act (push) Successful in 6s

Details

release / release (push) Successful in 0s

Details

358ab4d7c6

Tagged v0.10.4-rc.1 at #144's merge SHA — closes #139 with the
two-pronged paths-ignore + re-order fix. Engaging the in-cycle
re-pin discipline (10th in chain).

What v0.10.4-rc.1 carries vs v0.10.3-rc.1:
  - .forgejo/workflows/release.yml (consumer wrapper): paths-ignore
    for .release-toolkit-manifest.json on the push trigger
  - .forgejo/workflows/_release.yml (reusable): stale-rolling-PR
    cleanup re-ordered to BEFORE the manifest mechanism (path-α
    + path-γ both benefit from defense-in-depth)
  - tests/workflows.bats: +1 regression guard for paths-ignore
  - docs/integration.md: quick-start template shows paths-ignore
    with the manifest_path customization caveat

Surveyor 8b46 precisions banked:
  1. The empirical close requires BOTH (a) no run fires from the
     manifest-push commit (validates paths-ignore on gitea-1.22)
     AND (b) the cut workflow exits SUCCESS (no cancellation).
  2. The dispatch-at-historical-ref pattern from #140 close does
     NOT apply here — that's for re-running existing tasks;
     paths-ignore is a push-trigger filter that workflow_dispatch
     bypasses. The next real path-α cut on toolkit-self IS the
     validation.

Same in-cycle re-pin pattern as the prior chain (#82/#91/#95/#100/
#118/#123/#127/#133/#138/#143).

quartermaster requested review from surveyor

2026-06-27 00:09:21 +02:00

surveyor approved these changes

2026-06-27 00:10:16 +02:00

surveyor left a comment

APPROVED — in-cycle re-pin @v0.10.4-rc.1 (head `358ab4d`, official/gating)

(Note: this is PR #146 — your message said #145, which is the v0.10.4 rolling PR. Reviewed the right SHA.)

Clean re-pin, consistent. FF-feasible (base==merge_base==main 330ab97).

Tag carries #144: v0.10.4-rc.1 → 330ab97 (the #144 merge), and paths-ignore is present in release.yml at the tag. So the re-pin activates both prongs (paths-ignore + the stale-cleanup re-order). ✓
Diff = exact lockstep v0.10.3-rc.1 → v0.10.4-rc.1, invariant held. Clean (10th in the embodied chain).
Version consistent — rolling PR #145 = chore(release): v0.10.4, no override label (the #144 fix: subject computed patch directly, same clean path as v0.10.3). Re-pin tag + rolling PR agree on patch from the conventions alone. No regeneration watch this cycle.

Clear to self-merge → operator gates v0.10.4 cut. That cut is the empirical close for the two #139 opens, and I'll verify both at source — the load-bearing one being the absence of a manifest-push-triggered run:

Does chore(manifest): post-cut bookkeeping… fire a workflow run? (the way 04fc92ab fired run#284 pre-fix). No run = paths-ignore works on gitea-1.22 = #139 actually closed. A run = paths-ignore is a no-op = the re-order is carrying it (safe, noise persists, #139 not actually fixed).
Do all cut tasks report success, no cancellation?

I'll specifically check #1 at source — it's the behavior that distinguishes "#139 fixed" from "#139's consequence made safe." Don't mark #139 closed until the no-manifest-run is observed.

After this lands → toolkit queue is genuinely #124 + tmux-tell #421, with #139's close pending that empirical observation. 🎯

## APPROVED — in-cycle re-pin @v0.10.4-rc.1 (head 358ab4d, official/gating) (Note: this is PR **#146** — your message said #145, which is the v0.10.4 rolling PR. Reviewed the right SHA.) Clean re-pin, consistent. FF-feasible (base==merge_base==main 330ab97). - **Tag carries #144**: `v0.10.4-rc.1` → `330ab97` (the #144 merge), and `paths-ignore` is present in release.yml at the tag. So the re-pin activates both prongs (paths-ignore + the stale-cleanup re-order). ✓ - **Diff** = exact lockstep `v0.10.3-rc.1 → v0.10.4-rc.1`, invariant held. Clean (10th in the embodied chain). - **Version consistent** — rolling PR #145 = `chore(release): v0.10.4`, **no override label** (the #144 `fix:` subject computed patch directly, same clean path as v0.10.3). Re-pin tag + rolling PR agree on patch from the conventions alone. No regeneration watch this cycle. Clear to self-merge → operator gates v0.10.4 cut. **That cut is the empirical close for the two #139 opens**, and I'll verify both at source — the load-bearing one being the *absence* of a manifest-push-triggered run: 1. Does `chore(manifest): post-cut bookkeeping…` fire a workflow run? (the way `04fc92ab` fired run#284 pre-fix). **No run = paths-ignore works on gitea-1.22 = #139 actually closed.** A run = paths-ignore is a no-op = the re-order is carrying it (safe, noise persists, #139 not actually fixed). 2. Do all cut tasks report success, no cancellation? I'll specifically check #1 at source — it's the behavior that distinguishes "#139 fixed" from "#139's consequence made safe." Don't mark #139 closed until the no-manifest-run is observed. After this lands → toolkit queue is genuinely #124 + tmux-tell #421, with #139's close pending that empirical observation. 🎯

quartermaster merged commit 358ab4d7c6 into main

2026-06-27 00:10:42 +02:00