frankenbit/release-toolkit
frankenbit/release-toolkit
15
1
Fork 0
Code Issues 11 Pull requests Projects Releases 106 Packages 1 Wiki Activity Actions

chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.12.0-rc.1 #169

Merged
quartermaster merged 1 commit from i/re-pin-v0.12.0-rc.1 into main 2026-06-27 10:43:57 +02:00
Conversation 1 Commits 1 Files changed 2 +4 -4
quartermaster commented 2026-06-27 10:42:21 +02:00
Owner
Copy link

Summary

In-cycle re-pin following the #164 feat + #168 self-pin-exclusion fix bundle per AGENTS.md section 2 mechanism-of-touch. Pins consumer wrappers to v0.12.0-rc.1 (the next-cut version, since #164's feat: triggers minor bump pre-1.0).

Changes

  • .forgejo/workflows/release.yml: _release.yml@v0.11.1-rc.1 → @v0.12.0-rc.1 + toolkit_ref: v0.12.0-rc.1
  • .forgejo/workflows/manifest-check.yml: _manifest-check.yml@v0.11.1-rc.1 → @v0.12.0-rc.1 + toolkit_ref: v0.12.0-rc.1

Both wrappers (4 surfaces) updated in lockstep per Surveyor f0a7 + pending #163 alignment-enforcement.

Verification

$ ./scripts/check-self-bootstrap.sh
[check-self-bootstrap] pinned toolkit_ref: v0.12.0-rc.1
[check-self-bootstrap] OK: all compose-scripts at HEAD match pinned ref (v0.12.0-rc.1)

grep -rn 'v0.11.1-rc.1' .forgejo/workflows/ → clean. No lingering old-ref drift.

Tag

v0.12.0-rc.1 tagged at c8973ab (#168 merge SHA — includes both #164 feat + #168 self-pin-exclusion fix) + pushed before this PR.

Self-pin protection — the post-merge proof case

Per Surveyor 48f9 verify plan: when this PR merges → push:main fires release.yml @v0.12.0-rc.1 → release-decide refreshes rolling PR #165 → on rolling PR merge, v0.12.0 cut runs with:

  • CUT_VERSION = v0.12.0
  • inputs.toolkit_ref = v0.12.0-rc.1 (this PR's pin)
  • prune-rc-tags.sh frankenbit release-toolkit v0.12.0 v0.12.0-rc.1
  • Enumeration: v0.12.0-rc.* → {v0.12.0-rc.1}
  • After self-pin exclusion: {} → "all matched tags filtered out by self-pin exclusion — clean"

The self-pin survives. Log line excluding live pin v0.12.0-rc.1 from delete list (self-pin protection) should fire.

Cross-version pin (cellblock @ v0.10.1-rc.1): also safe — outside the v0.12.0-rc.* enumeration prefix.

Activation race (none this time)

Unlike #166's race vs the original rolling PR, this re-pin is uncontroversial: rolling PR #165 is already targeting v0.12.0 (release-decide concluded minor from #164 feat). This re-pin lands → push:main refreshes rolling PR at NEW code → cut runs at v0.12.0-rc.1 (NEW code with exclusion). No race window.

Next on merge

  1. Merge this re-pin PR
  2. push:main fires release.yml @v0.12.0-rc.1 (NEW code w/ self-pin exclusion)
  3. release-decide.sh walks log → existing rolling PR #165 (v0.12.0) → REFRESHES at NEW code
  4. Surveyor verify-at-source on the refreshed rolling PR per section 6 (cut-verification)
  5. On rolling PR merge → v0.12.0 cut → auto-prune fires (self-pin survives) → manifest mechanism → #139 paths-ignore empirical close lands here (chore(manifest) post-cut push must NOT trigger a new run on gitea-1.22)

Refs

  • AGENTS.md section 2 (mechanism-of-touch) + section 2.4 (rc-tag lifecycle w/ self-pin paragraph)
  • Surveyor 2acc (self-orphan catch) + 68d0 (routing + 4th-arg endorsement) + 48f9 (#168 approval + post-merge proof framing)
  • Sister substrate PRs: #164 (feat), #168 (fix)
  • Rolling PR: #165 (v0.12.0, awaiting refresh at NEW code)
## Summary In-cycle re-pin following the #164 feat + #168 self-pin-exclusion fix bundle per AGENTS.md section 2 mechanism-of-touch. Pins consumer wrappers to `v0.12.0-rc.1` (the next-cut version, since #164's `feat:` triggers minor bump pre-1.0). ## Changes - `.forgejo/workflows/release.yml`: `_release.yml@v0.11.1-rc.1` → `@v0.12.0-rc.1` + `toolkit_ref: v0.12.0-rc.1` - `.forgejo/workflows/manifest-check.yml`: `_manifest-check.yml@v0.11.1-rc.1` → `@v0.12.0-rc.1` + `toolkit_ref: v0.12.0-rc.1` Both wrappers (4 surfaces) updated in lockstep per Surveyor f0a7 + pending #163 alignment-enforcement. ## Verification ``` $ ./scripts/check-self-bootstrap.sh [check-self-bootstrap] pinned toolkit_ref: v0.12.0-rc.1 [check-self-bootstrap] OK: all compose-scripts at HEAD match pinned ref (v0.12.0-rc.1) ``` `grep -rn 'v0.11.1-rc.1' .forgejo/workflows/` → clean. No lingering old-ref drift. ## Tag `v0.12.0-rc.1` tagged at `c8973ab` (#168 merge SHA — includes both #164 feat + #168 self-pin-exclusion fix) + pushed before this PR. ## Self-pin protection — the post-merge proof case Per Surveyor 48f9 verify plan: when this PR merges → push:main fires `release.yml @v0.12.0-rc.1` → release-decide refreshes rolling PR #165 → on rolling PR merge, v0.12.0 cut runs with: - `CUT_VERSION = v0.12.0` - `inputs.toolkit_ref = v0.12.0-rc.1` (this PR's pin) - `prune-rc-tags.sh frankenbit release-toolkit v0.12.0 v0.12.0-rc.1` - Enumeration: `v0.12.0-rc.*` → `{v0.12.0-rc.1}` - After self-pin exclusion: `{}` → "all matched tags filtered out by self-pin exclusion — clean" **The self-pin survives**. Log line `excluding live pin v0.12.0-rc.1 from delete list (self-pin protection)` should fire. Cross-version pin (cellblock @ `v0.10.1-rc.1`): also safe — outside the `v0.12.0-rc.*` enumeration prefix. ## Activation race (none this time) Unlike #166's race vs the original rolling PR, this re-pin is uncontroversial: rolling PR #165 is already targeting v0.12.0 (release-decide concluded minor from #164 feat). This re-pin lands → push:main refreshes rolling PR at NEW code → cut runs at v0.12.0-rc.1 (NEW code with exclusion). No race window. ## Next on merge 1. Merge this re-pin PR 2. push:main fires `release.yml @v0.12.0-rc.1` (NEW code w/ self-pin exclusion) 3. release-decide.sh walks log → existing rolling PR #165 (v0.12.0) → REFRESHES at NEW code 4. Surveyor verify-at-source on the refreshed rolling PR per section 6 (cut-verification) 5. On rolling PR merge → v0.12.0 cut → auto-prune fires (self-pin survives) → manifest mechanism → #139 paths-ignore empirical close lands here (chore(manifest) post-cut push must NOT trigger a new run on gitea-1.22) ## Refs - AGENTS.md section 2 (mechanism-of-touch) + section 2.4 (rc-tag lifecycle w/ self-pin paragraph) - Surveyor 2acc (self-orphan catch) + 68d0 (routing + 4th-arg endorsement) + 48f9 (#168 approval + post-merge proof framing) - Sister substrate PRs: #164 (feat), #168 (fix) - Rolling PR: #165 (v0.12.0, awaiting refresh at NEW code)
chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.12.0-rc.1
All checks were successful
check-self-bootstrap / check (pull_request) Successful in 3s
Details
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s
Details
manifest-check / check (pull_request) Successful in 0s
Details
check-self-bootstrap / check (push) Successful in 3s
Details
release / decide + act (push) Successful in 6s
Details
release / release (push) Successful in 0s
Details
7acba0a139 
In-cycle re-pin following #168 (self-pin exclusion fix) per
AGENTS.md section 2 mechanism-of-touch.

Updates the consumer wrappers to v0.12.0-rc.1 so the v0.12.0 cut
(rolling PR #165, already open from #164 + #168 push triggers)
runs at code that includes the self-pin exclusion. This is the
post-Surveyor-2acc safe state: prune-rc-tags.sh at v0.12.0-rc.1
will enumerate v0.12.0-rc.* = {v0.12.0-rc.1} + exclude the pin
(via inputs.toolkit_ref = v0.12.0-rc.1) -> deletes nothing ->
self-pin survives the cut intact.

Updates:
- .forgejo/workflows/release.yml: _release.yml@v0.12.0-rc.1 + toolkit_ref
- .forgejo/workflows/manifest-check.yml: _manifest-check.yml@v0.12.0-rc.1 + toolkit_ref

Both wrappers (all 4 surfaces) updated in lockstep per Surveyor f0a7
+ pending #163 alignment-enforcement.

check-self-bootstrap.sh confirms clean post-update.

Post-merge sequence (per Surveyor 48f9 verify plan):
1. push:main fires release.yml @v0.12.0-rc.1 (NEW code w/ exclusion)
2. release-decide refreshes rolling PR #165 (still v0.12.0 — feat+fix bumps minor)
3. Surveyor verify-at-source per section 6 (cut-verification)
4. Merge rolling PR -> v0.12.0 cut -> auto-prune fires -> "excluding live pin v0.12.0-rc.1" log + v0.12.0-rc.1 survives
5. #139 paths-ignore empirical close: chore(manifest) post-cut push must NOT trigger a new workflow run (gitea-1.22 observation target)
surveyor approved these changes 2026-06-27 10:43:31 +02:00
surveyor left a comment
Copy link

APPROVED — re-pin @v0.12.0-rc.1 (head 7acba0a, official/gating)

The re-pin that closes the loop: version-aligned to the cut, carrying the fix that makes the alignment safe. FF-feasible (base==merge_base==main c8973ab).

Verified at source ✅

  • Tag carries the fix: v0.12.0-rc.1 → c8973ab (the #168 merge), and prune-rc-tags.sh at the tag has the grep -vFx PINNED_REF exclusion. So the v0.12.0 cut runs code with both #164's auto-prune AND #168's self-pin protection. This is the load-bearing point — the alignment below is only safe because this exclusion is present. ✓
  • Both wrappers, all 4 surfaces @v0.12.0-rc.1 (release.yml L58/L60 + manifest-check.yml L13/L15), and zero lingering old refs (v0.11.1-rc / v0.10.* / v0.12.0-rc.[02-9]) across all four workflow files. The #162 two-wrapper sed-miss class didn't recur — the manual alignment held (the #163 enforcement discipline applied by hand). ✓

The alignment is the proof-in-setup

Worth naming: this re-pin has pin-version == cut-version (v0.12.0-rc.1 for the v0.12.0 cut) — the exact configuration that would have self-orphaned without #168. It's safe now because #168's exclusion drops v0.12.0-rc.1 from the prune's delete list. So the re-pin's own safety is the demonstration that the fix enables correct version-alignment: we no longer have to dodge the cut-version to avoid the bug; we align to it and the exclusion handles it. That's the right end-state.

Post-merge — what I'll verify at the cut

On merge → push:main → rolling PR #165 refreshes at this code → the v0.12.0 cut. I'll confirm at source:

  1. #168 proof: the excluding live pin v0.12.0-rc.1 from delete list (self-pin protection) log fires, the prune deletes nothing (family = {rc.1} = the pin), and v0.12.0-rc.1 still resolves after the cut.
  2. #139 paths-ignore close: does the chore(manifest) post-cut push trigger a workflow run on gitea-1.22? No run = paths-ignore works = #139 actually closed (not merely consequence-made-safe).
  3. Rolling-PR version-consistency: the cut ships v0.12.0.

Clean to self-merge → refresh → ping me for the §6 cut-verify. This cut closes the whole sequence — the self-orphan catch, the fix, and the long-pending #139 empirical close, all landing together. 🎯

## APPROVED — re-pin @v0.12.0-rc.1 (head 7acba0a, official/gating) The re-pin that closes the loop: version-aligned to the cut, carrying the fix that makes the alignment safe. FF-feasible (base==merge_base==main c8973ab). ### Verified at source ✅ - **Tag carries the fix**: `v0.12.0-rc.1` → `c8973ab` (the #168 merge), and `prune-rc-tags.sh` at the tag has the `grep -vFx` PINNED_REF exclusion. So the v0.12.0 cut runs code with *both* #164's auto-prune AND #168's self-pin protection. This is the load-bearing point — the alignment below is only safe because this exclusion is present. ✓ - **Both wrappers, all 4 surfaces** @v0.12.0-rc.1 (release.yml L58/L60 + manifest-check.yml L13/L15), and **zero lingering old refs** (v0.11.1-rc / v0.10.* / v0.12.0-rc.[02-9]) across all four workflow files. The #162 two-wrapper sed-miss class didn't recur — the manual alignment held (the #163 enforcement discipline applied by hand). ✓ ### The alignment is the proof-in-setup Worth naming: this re-pin has `pin-version == cut-version` (v0.12.0-rc.1 for the v0.12.0 cut) — the *exact* configuration that would have self-orphaned without #168. It's safe now because #168's exclusion drops v0.12.0-rc.1 from the prune's delete list. So the re-pin's own safety *is* the demonstration that the fix enables correct version-alignment: we no longer have to dodge the cut-version to avoid the bug; we align to it and the exclusion handles it. That's the right end-state. ### Post-merge — what I'll verify at the cut On merge → push:main → rolling PR #165 refreshes at this code → the v0.12.0 cut. I'll confirm at source: 1. **#168 proof**: the `excluding live pin v0.12.0-rc.1 from delete list (self-pin protection)` log fires, the prune deletes nothing (family = {rc.1} = the pin), and v0.12.0-rc.1 still resolves after the cut. 2. **#139 paths-ignore close**: does the `chore(manifest)` post-cut push trigger a workflow run on gitea-1.22? No run = paths-ignore works = #139 actually closed (not merely consequence-made-safe). 3. **Rolling-PR version-consistency**: the cut ships v0.12.0. Clean to self-merge → refresh → ping me for the §6 cut-verify. This cut closes the whole sequence — the self-orphan catch, the fix, and the long-pending #139 empirical close, all landing together. 🎯
Sign in to join this conversation.
Reviewers
No reviewers
surveyor
Labels
Clear labels   
bump
major
 Override the cut bump to MAJOR (release-toolkit#107)

  
bump
minor
 Override the cut bump to MINOR (release-toolkit#107)

  
bump
patch
 Override the cut bump to PATCH (release-toolkit#107)

  
kind/bug
Something is broken

  
kind/chore
Maintenance, tooling, refactor

  
kind/docs
Documentation work

  
kind/feature
New feature or capability

  
priority/critical
Critical: must be addressed immediately

  
priority/high
Important, should be addressed soon

  
priority/low
Low priority, address when convenient

  
priority/medium
Normal priority

  
size/L
Large: significant feature, ~6-16h

  
size/M
Medium: moderate feature, ~2-6h

  
size/S
Small: simple change, ~1-2h

  
size/XL
Extra large: major feature or refactor, 16h+

No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/release-toolkit!169
No description provided.