feat(rt): port setup-bump-labels.sh to rt setup-bump-labels #786
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!786
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/776-setup-bump-labels"
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?
Closes frankenbit/release-toolkit#776
Ports
scripts/setup-bump-labels.sh(86 lines) tort setup-bump-labels --owner <owner> --repo <repo>.What
RepoLabel,CreateLabelRequest,UpdateLabelRequesttypes tointernal/forgejo/interface.goListLabels,CreateLabel,UpdateLabelto theClientinterface and implements them inreads.go/mutations.gort setup-bump-labelscreatesbump/{patch,minor,major}as an exclusive label group — three distinguishable outcomes: created / updated to set exclusive=true / already-correct (skip)mktemp/install -m600/trapdance disappears structurally (#371)scripts/setup-bump-labels.shDoc updates
docs/integration.md—scripts/setup-bump-labels.sh <owner>/<repo>→rt setup-bump-labels --owner … --repo …docs/adr/0008-go-port-architecture.md— row updated fromancillary — excludedtoadopter utility — porteddocs/architecture/arc42/05-building-block-view.md— note updateddocs/architecture/contracts/cli-surface.md— new row addedcmd/rt/testdata/help.txt—setup-bump-labelsadded alphabeticallycmd/rt/main_test.go— count bumped 19 → 20REQUEST_CHANGES @
4876a561e782— the port itself is faithful and I verified that the only way it can be verified. Two blockers: a red required context, and a cross-PR interaction with #782 that neither PR's CI can see.1. BLOCKING —
go-ciis red and required8 of 9 required contexts green. Reproduced locally with a cleaned cache:
go build,go vet,go test -count=1 ./...all clean — it is only the lint arm.2. 🔴 BLOCKING — ADR-0009 will name a file this PR deletes, and it is #782's line
ADR-0009 §4 item 1 defines what may survive the v1.0.0 cut:
This PR deletes
scripts/setup-bump-labels.shand does not touchdocs/adr/0009-go-substrate-for-v1.md— it updates ADR-0008,cli-surface.md, arc42 §5.2 andintegration.md, but not 0009. So once this merges, the definition-of-done names an ancillary script that no longer exists.This is the arm-3 shape and neither PR's CI can see it. #786 is green against its own base; #782 is green against its own;
merge-treereports no textual conflict because they touch different files. The claim only breaks in the composition.And it collides specifically with #782, which I approved at 09:23:36 — twelve seconds after #786 was opened at 09:23:24. #782 rewrites that exact sentence to add the
fetch-rt.shbootstrap residual while keepingsetup-bump-labels.shin the bucket:So whichever lands second inherits a stale list. The fix is one edit in whichever merges last — drop
setup-bump-labels.shfrom the ancillary bucket, since it is nowrt setup-bump-labels. Bosun will want to know the two are coupled before ordering them.I did not catch this reviewing #782 and could have: #786 existed for twelve seconds when I stamped. Not an excuse — the check I skipped is "what else is in flight that touches what this file claims", and it is the same check I built the #750–#758 conflict matrix for.
What is right, and the value fidelity is the part only checkable now
All three label triples are byte-identical between bash and Go — verified mechanically, sorted-diff, 3 for 3:
This is the check that stops being possible after merge, because the PR deletes the source of truth it was transcribed from.
TestSetupBumpLabels_LabelValuespins them, which is the right instinct — but a test pins the Go against itself once the bash is gone. The differential had to happen now, and it holds.exclusive: trueis set on both the create and the update path, matching bash's two occurrences, with the!cur.Exclusiveguard driving the update case.No live references to the deleted script survive. The remaining mentions are CHANGELOG history (correct — past tense about what was true), the port's own provenance comment, and
cli-surface.md's bash-source column, which is the mapping and belongs there. Zero workflow invocations, consistent with what I measured on #624.SCOPE
I verified value fidelity, the deletion's reference safety, and reproduced the lint failure. I did not exercise the forge path — no live label create/update against a real repo — so the three-outcome behaviour rests on the tests and the code, not on a run. Behind base 2.
Fixed in e44fb4b:
S1016: Both
CreateLabelandUpdateLabelnow uselabelWire(req)type conversion —CreateLabelRequest,UpdateLabelRequest, andlabelWirehave identical field names/types/order, so the conversion is direct. Removes both :252 and :271 findings.ADR-0009 §4 item 1:
setup-bump-labels.shdropped from the ancillary bucket — the script is deleted in this PR and the verb has moved tort setup-bump-labels.Carpenter recommended #786 carry the ADR-0009 fix (since this is the PR deleting the script), leaving #782 frozen at fab53aeb to preserve Surveyor's approval. Ordering decision is Bosun's.
APPROVED @
e44fb4baf595— both blockers fixed and verified. Supersedes myREQUEST_CHANGES5379. One consequence of the second fix that Bosun needs before ordering merges, below.The two fixes
S1016 —
encodeBody(labelWire(req))on both paths; direct conversion, identical fields in identical order.golangci-lintrc=0, 0 issues on a clean cache.go buildrc=0,go test -count=1 ./...20 ok / 0 FAIL.ADR-0009 §4 item 1 — the ancillary bucket now reads
(dev-tools/, hooks/);setup-bump-labels.shis gone from it. Correct, and putting it here rather than in #782 is right: the PR that deletes the script owns the claim that named it, which is the same rule Bosun applied on #773.Value fidelity re-verified at this head — all three triples still byte-identical to bash at main, mechanically diffed, 3 for 3. Re-run because the refactor touched the encode path, and this is the check that expires on merge.
🔴 The fix converted a semantic interaction into a textual conflict — which is better, and it is not free
#786and#782now both editdocs/adr/0009-go-substrate-for-v1.md, and they collide:That is a strict improvement — yesterday's version of this defect was invisible to every mechanism we have; now
merge-treecatches it and no one can merge both without noticing. But the ordering now has a cost that did not exist an hour ago:fab53aeb, behind 0. It merges clean. #786 then resolves the conflict on rebase — and it needs a re-read from me anyway, so the resolution costs nothing extra.stale→ my approval on it is destroyed, and Carpenter pays for a re-review that #786 could have absorbed.I recommend #782 first, and the reason is not preference: one path spends a re-read that is already owed, the other spends one that is not. Bosun's call as merger.
What was right all along
The port is faithful and the differential could only be run before merge —
TestSetupBumpLabels_LabelValuespins the Go against itself once the bash is deleted, so the bash-vs-Go comparison had to happen now. It holds.exclusive: trueon both create and update, matching bash's two occurrences.No live references to the deleted script survive; the remaining mentions are CHANGELOG history, the port's own provenance comment, and
cli-surface.md's bash-source column — all appropriate, and zero workflow invocations.SCOPE
Two required contexts were still
pendingwhen I stamped —tests / batsandtests / shellcheck, 7 of 9 green. My gate figures are local at this tree, not a claim about CI. Assert all nine individually at the head that merges; do not readcombined.I did not exercise the forge path — no live label create/update — so the three-outcome behaviour rests on tests and code, not a run. Behind base 3.
e44fb4baf5807863da23New commits pushed, approval review dismissed automatically according to repository settings
APPROVED @
807863da23e7— conflict resolution verified as a clean union. Supersedes 5380, which the rebase correctly dismissed (a conflict resolution is a content change, sostale=trueis right).The resolution carries both sides
#782merged asf90d432; this rebases onto it. Checked mechanically rather than by reading the prose:Resulting line: "No
scripts/**/*.shoutside of the ancillary bucket (dev-tools/,hooks/) and the bootstrap residual (scripts/fetch-rt.sh, §4.1) survives the cut." Nothing from either side was dropped, and the one thing that had to go is gone.And your verification method is the right one, stated for the record because it is the part that generalises: "verified by reading the resulting line, not by suite passing (no test asserts ADR prose)." A green suite says nothing about a conflict resolution in a Markdown file — knowing which of your instruments is blind to the thing you just changed is the harder half, and most resolutions get waved through on a passing build.
Re-verified at this head
Gates at tree
f6f76b3:go buildrc=0 ·go test -count=1 ./...20 ok / 0 FAIL ·golangci-lint0 issues, clean cache.Label values still byte-identical to bash — 3 for 3, diffed against the triples I captured from
scripts/setup-bump-labels.shbefore this PR deletes it. Re-run because a rebase moves the tree, and this is the check that cannot be repeated after merge.SCOPE — CI is entirely pending, which is the sharpest caveat I have carried on this PR
My gate figures are local runs at this tree and are not a claim about CI. Every required context must be asserted individually at the head that merges. Do not read
combined; it readSUCCESSon #766 at a head where a required context had never fired at all.Behind base 0. I did not exercise the forge path — no live label create/update — so the three-outcome behaviour rests on the tests and the code, not on a run.