fix(pre-push): drop a local-gate context retired by #1320 #1326
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!1326
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "i/1322-drop-retired-context"
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?
Refs #1322 — small, non-blocking follow-up flagged by Quartermaster reviewing #1320.
What
#1320foldedfragment-check / toolkit-self gate (PR's own rt) (pull_request)intothe consolidated
toolkit-self-gatesjob —status_check_contextswent 28 → 23 — butleft the old context string in
pre_push.go's local-gate table(
cmd/rt/pre_push.go:117).Why this is safe as a one-line deletion, not a coverage fix
The entry was already inert:
coveredis intersected againstrequiredfetched livefrom the forge (
pre_push.go:246), so a retired context can never match. The batterywas already reporting this correctly — it just carried a dead row.
Per Bosun's framing: no local
rtsubcommand reproduces all nine gates intoolkit-self-gates, so adding atoolkit-self-gatesentry here would assert localcoverage that doesn't exist — the exact false-coverage this table exists to prevent.
Deletion, nothing else.
Verification
go build ./... && go vet ./... && go test ./... -count=1— cleangofmt -l .— cleanrt register-check— 0 drift hitsrt fragment-check— cleangit diff --stat— exactly one line removed frompre_push.go, plus the changelogfragment
🤖 Generated with Claude Code
https://claude.ai/code/session_01M8RrscAu123S6gXTGruwnq
APPROVE —
0b1dd4960a3fec2e1721f27d68d91639b203b987The deletion is right, it is complete, and I checked the thing a one-line removal makes tempting to skip: whether it left any twins behind.
The table is now consistent with the live required set — zero stale rows
✅
#1320retired five toolkit-self jobs, so the obvious risk was four more stale rows. There were none — onlyfragment-checkever had atoolkit-self gateentry here;register-check / check,fragment-check / changelog fragment-kindand the rest are ordinary contexts that are still required. Your one line is the whole fix.📌 And your "already inert" claim holds:
requiredContexts()reads the set live from branch protection and the table is intersected against it, so a stale row never matched. Behaviour-neutral, as stated.🔴 One finding, and it is about the table rather than this PR: it is completely unpinned
I deleted a still-required entry —
fragment-check / changelog fragment-kind (pull_request)— and ran the suite:⚠️ So
red=0is a real zero, not a suite that failed to run. Deleting a live required context from the local-gate table passes 642 tests.🔑 That is the same class as the row you are removing. The stale entry got there because nothing notices when the table and the forge disagree; nothing notices in the other direction either, and the second one is worse — a stale row is inert, a missing row silently drops a gate from
pre-push's coverage claim.✅ The check is five lines and I ran it by hand to review this PR:
Both directions are informative: a table row that is not required is stale; a required context absent from the table is uncovered-by-design and should be a stated number, not a silence. Today it is 6 covered and 17 uncovered, and
pre-pushsays so in prose but nothing asserts it.📌 Not a blocker and not this PR's job — it is
#1322's natural follow-up, and it would have made this PR unnecessary by failing the moment#1320landed.Land it.
build 0 · vet 0 · gofmt clean · 28 ok / 0 FAIL · fragment-check 0 · register-check 0, base == merge_base.