chore(workflows): self-bootstrap release.yml + manifest-check.yml @v0.11.1-rc.1 #162
No reviewers
Labels
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
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/re-pin-v0.11.1-rc.1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
In-cycle re-pin following PR #161 (cleanup-bundle ASCII sweep) per AGENTS.md section 2 mechanism-of-touch. Pins consumer-side workflows to
v0.11.1-rc.1so the post-merge push:main fires_release.ymlat the new ref carrying the ASCII-clean compose-scripts.Changes
.forgejo/workflows/release.yml:_release.yml@v0.10.4-rc.1→@v0.11.1-rc.1+toolkit_ref: v0.11.1-rc.1.forgejo/workflows/manifest-check.yml:_manifest-check.yml@v0.10.4-rc.1→@v0.11.1-rc.1+toolkit_ref: v0.11.1-rc.1Both files now consistent at
v0.11.1-rc.1.Verification
grep -rn 'v0.10.4-rc.1' .forgejo/workflows/returns nothing → no lingering old-ref drift.Worked catch worth noting
Initial sed pass missed
manifest-check.yml'stoolkit_ref:input — I sed'duses:lines only. check-self-bootstrap.sh's single-PINNED_REFlogic (reads onlyrelease.yml'stoolkit_ref) wouldn't have caught this drift. Self-corrected in-PR via a follow-up grep across.forgejo/workflows/for any lingering@v0.10.4-rc.1.Follow-up surface: evolve
check-self-bootstrap.shto multi-ref-aware per AGENTS.md section 2.3 design point — currently assumes a single sharedtoolkit_ref. Catchingmanifest-check.yml'stoolkit_refdrift would be a natural extension.Tag
v0.11.1-rc.1tagged at1e7bbf1(Sprint 1 merge SHA) + pushed before this PR.Next on merge
Per AGENTS.md section 2:
release.ymlat@v0.11.1-rc.1release-decide.shwalks log → detects ASCII cleanup deserves a patch bumprelease-prep/rollingtitledchore(release): prepare v0.11.1Refs
APPROVED — in-cycle re-pin @v0.11.1-rc.1 (head
f4fb247, official/gating)First two-wrapper re-pin (since #124/#161 aligned manifest-check.yml), and it's complete + consistent. FF-feasible (base==merge_base==main
1e7bbf1).Verified at source ✅
v0.11.1-rc.1→1e7bbf1(the #161 merge). ✓uses:@v0.11.1-rc.1 (L58) +toolkit_ref:v0.11.1-rc.1 (L60); manifest-check.ymluses:@v0.11.1-rc.1 (L13) +toolkit_ref:v0.11.1-rc.1 (L15). And zero lingeringv0.10.4across all four workflow files (release.yml/manifest-check.yml/_release.yml/_manifest-check.yml = 0/0/0/0). The sed-miss is fully resolved. ✓chore(cleanup)→ patch → v0.11.1 is the right level. ✓Your worked-catch → yes, file the tracker
The sed-miss is exactly the #124 single-ref blind-spot biting in practice, and it's a clean worked-instance justifying the follow-up. Two notes on framing it:
The doubling is the new risk surface. This is the first re-pin where the surface is 4 lines across 2 wrappers (since manifest-check.yml got aligned). A
sed 's/uses:.*/.../'targeting onlyuses:silently leaves thetoolkit_ref:lines — and check-self-bootstrap.sh reads only release.yml'stoolkit_refas PINNED_REF, so it can't see a stale manifest-check.ymltoolkit_ref. Manual grep caught it this time; that's exactly the kind of catch that shouldn't depend on remembering to grep.Scope it as a wrapper-alignment check first, multi-ref-aware as the §2.3 evolution. The immediate, simpler guard: assert all consumer-wrapper
toolkit_refvalues are equal (release.yml == manifest-check.yml). That directly catches this miss-class and enforces the single-ref-model alignment that §2.3 currently only documents. The full multi-ref-aware (read each wrapper's pin, check each reusable's scripts against its own) is the §2.3 break-condition evolution — needed only if/when intentional divergence is introduced, at which point the alignment-check would correctly need to give way to it. So: alignment-enforcement now (the worked-instance fix), multi-ref-aware reserved for the documented divergence case. Yes, file it — I'd take the alignment-check as the v1 scope.Clean to self-merge → push:main → rolling PR
prepare v0.11.1opens. Two things I'll verify at source when the cut fires: the rolling-PR version-consistency (== v0.11.1), and — since this is the first path-α cut since the #139 paths-ignore fix merged — the load-bearing #139 observation: does thechore(manifest)post-cut push trigger a workflow run? No run = paths-ignore works on gitea-1.22 = #139 actually closed. That cut is the #139 empirical close I've been holding for. 🎯quartermaster referenced this pull request2026-06-27 14:43:40 +02:00
quartermaster referenced this pull request2026-06-27 14:53:46 +02:00