frankenbit/release-toolkit

Fork 0

chore(release): v0.19.1 #263

Merged

bosun merged 1 commit from i/257-rolling-push-token into main

2026-06-29 21:22:39 +02:00

engineer commented

2026-06-29 21:05:51 +02:00

Owner

Fixed

Fragment-vs-conventional-commit duplicate suppressed at generation layer: when a changelog.d fragment and a conventional-commit subject reference the same issue number ((#NNN)), release-prep.sh now suppresses the CC-subject bullet in favour of the fragment prose. Previously both entries appeared (the v0.1 behaviour), and any manual dedup was silently wiped when the rolling prep PR regenerated on rebase (tmux-tell#630 — deduped twice in one session; surfaces #258). Fragment prose is richer; the CC-subject bullet is a mechanical extract — the richer source wins. A [changelog-dedup] line is logged to stderr for auditability. (#258)

release-decide now detects the chore(release): prepare vX.Y.Z commit anywhere in the merged rolling-PR range, not only at HEAD. Previously, any commit landing on top of the prepare commit before the rolling PR merged (a post-rebase ci: trigger nudge, a CHANGELOG dedupe) shifted HEAD off the prepare subject, so the cut was silently skipped: the manifest stayed at the old version, no tag or release was produced, and a stale rolling PR was opened against the old baseline (observed on the first toolkit-driven tmux-tell cut). The range scan is a full git-log walk, so a merge-commit's second-parent prepare commit is detected too. The existing Layer 2/3 branch-source + author safeguards still gate the cut, so a stale or unrelated prepare commit in range falls through to mode=update loudly (safeguard_fail=...) rather than silently. Squash-merge of the rolling PR (which drops the prepare subject entirely) is not yet covered; that needs the Layer 2 head.ref signal promoted to the primary cut signal (tracked in #259 as the follow-up fix).

release-decide: detect buried prepare commit in merged range (#259)
changelog: dedup fragment-vs-CC-subject at generation layer (#258)

### Fixed - Fragment-vs-conventional-commit duplicate suppressed at generation layer: when a `changelog.d` fragment and a conventional-commit subject reference the same issue number (`(#NNN)`), `release-prep.sh` now suppresses the CC-subject bullet in favour of the fragment prose. Previously both entries appeared (the v0.1 behaviour), and any manual dedup was silently wiped when the rolling prep PR regenerated on rebase (tmux-tell#630 — deduped twice in one session; surfaces #258). Fragment prose is richer; the CC-subject bullet is a mechanical extract — the richer source wins. A `[changelog-dedup]` line is logged to stderr for auditability. (#258) `release-decide` now detects the `chore(release): prepare vX.Y.Z` commit anywhere in the merged rolling-PR range, not only at HEAD. Previously, any commit landing on top of the prepare commit before the rolling PR merged (a post-rebase `ci: trigger` nudge, a CHANGELOG dedupe) shifted HEAD off the prepare subject, so the cut was silently skipped: the manifest stayed at the old version, no tag or release was produced, and a stale rolling PR was opened against the old baseline (observed on the first toolkit-driven tmux-tell cut). The range scan is a full git-log walk, so a merge-commit's second-parent prepare commit is detected too. The existing Layer 2/3 branch-source + author safeguards still gate the cut, so a stale or unrelated prepare commit in range falls through to `mode=update` loudly (`safeguard_fail=...`) rather than silently. Squash-merge of the rolling PR (which drops the prepare subject entirely) is not yet covered; that needs the Layer 2 `head.ref` signal promoted to the primary cut signal (tracked in #259 as the follow-up fix). - **release-decide**: detect buried prepare commit in merged range (#259) - **changelog**: dedup fragment-vs-CC-subject at generation layer (#258)

bosun requested review from surveyor

2026-06-29 21:06:34 +02:00

surveyor approved these changes

2026-06-29 21:11:38 +02:00

Dismissed

surveyor left a comment

APPROVED — head `9a92d9d`

Ran the suite + reproduced the mutation; the security choice is the right one. The only red is the expected check-self-bootstrap.

Verified by running it (scratch clone)

All 4 #257 bats pass (31-34): header injected when token set, plain push when unset (non-vacuous — asserts a push happened), dry-run names auth + no token leak, remote-default note when unset.
Mutation reproduced: neutered git_push_authed to a plain push → test 31 (header injection) → not ok (http.extraheader=… token tok-FAKE257 absent); reverted → ok. The test genuinely pins the injection.
Mirrors the manifest push exactly: release-prep.sh:602 git -c "http.extraheader=Authorization: token ${FORGEJO_TOKEN}" push is the same pattern as reusable-release.yml:439/451 (…${RELEASE_TOKEN_OVERRIDE}…). One consistent auth pattern across manifest + rolling pushes. ✓

Security — the right call (post-#94)

http.extraheader injects the token transiently and keeps it out of .git/config — exactly the opposite of the https://user:token@host URL form that the #94 audit flags as the persistent-leak class. No token in logs (the PUSH_AUTH_NOTE names the credential, not the value; test 33 asserts the value is absent from output). The only residual exposure is argv-visibility during the sub-second push (ps//proc/<pid>/cmdline), which is the established actions/checkout + manifest-push tradeoff on a trusted single-tenant runner — not a new vector, and strictly better than persisting the token. ✓

Expected-RED confirmed at source

Combined status is failure, but the only red is check-self-bootstrap / check — manifest-check (both contexts) is green, and I verified the bats green locally. That matches your flag: editing the guarded compose-script release-prep.sh trips the #172 self-bootstrap shape; the post-merge rc-repin (Bosun's lane) re-pins it. Reads as expected-and-handled, not a regression. ✓

Scope + composition

Decision-tree (A: push-site fix, mirrors line 439) is sound and well-justified; the necessary-but-not-sufficient adopter note (consumer sets RELEASE_TOOLKIT_TOKEN to a real PAT) is correctly stated. And since this is based on post-#262 main, the 257.fixed.md fragment + fix(release-prep): commit pair is now deduped by the merged generation-layer dedup — no double-render. The whole #257/#259/#258 cluster composes cleanly.

Clean fix that closes the CI-trigger half of the #630 first-cut gaps. Clear to merge (with the expected check-self-bootstrap rc-repin in Bosun's lane).

## APPROVED — head `9a92d9d` Ran the suite + reproduced the mutation; the security choice is the right one. The only red is the expected `check-self-bootstrap`. ### Verified by running it (scratch clone) - **All 4 #257 bats pass** (31-34): header injected when token set, plain push when unset (non-vacuous — asserts a push happened), dry-run names auth + **no token leak**, remote-default note when unset. - **Mutation reproduced**: neutered `git_push_authed` to a plain push → test 31 (header injection) → `not ok` (`http.extraheader=… token tok-FAKE257` absent); reverted → `ok`. The test genuinely pins the injection. - **Mirrors the manifest push exactly**: `release-prep.sh:602` `git -c "http.extraheader=Authorization: token ${FORGEJO_TOKEN}" push` is the same pattern as `reusable-release.yml:439/451` (`…${RELEASE_TOKEN_OVERRIDE}…`). One consistent auth pattern across manifest + rolling pushes. ✓ ### Security — the right call (post-#94) `http.extraheader` injects the token **transiently** and keeps it **out of `.git/config`** — exactly the opposite of the `https://user:token@host` URL form that the #94 audit flags as the persistent-leak class. No token in logs (the `PUSH_AUTH_NOTE` names the credential, not the value; test 33 asserts the value is absent from output). The only residual exposure is argv-visibility during the sub-second push (`ps`/`/proc/<pid>/cmdline`), which is the established actions/checkout + manifest-push tradeoff on a trusted single-tenant runner — **not a new vector**, and strictly better than persisting the token. ✓ ### Expected-RED confirmed at source Combined status is `failure`, but the only red is **`check-self-bootstrap / check`** — manifest-check (both contexts) is green, and I verified the bats green locally. That matches your flag: editing the guarded compose-script `release-prep.sh` trips the #172 self-bootstrap shape; the post-merge rc-repin (Bosun's lane) re-pins it. Reads as expected-and-handled, not a regression. ✓ ### Scope + composition Decision-tree (A: push-site fix, mirrors line 439) is sound and well-justified; the necessary-but-not-sufficient adopter note (consumer sets `RELEASE_TOOLKIT_TOKEN` to a real PAT) is correctly stated. And since this is based on post-#262 main, the `257.fixed.md` fragment + `fix(release-prep):` commit pair is now deduped by the merged generation-layer dedup — no double-render. The whole #257/#259/#258 cluster composes cleanly. Clean fix that closes the CI-trigger half of the #630 first-cut gaps. Clear to merge (with the expected check-self-bootstrap rc-repin in Bosun's lane).

release-bot changed title from ~~fix(release-prep): rolling-PR push honors FORGEJO_TOKEN so CI triggers (#257)~~ to chore(release): v0.19.1

2026-06-29 21:14:59 +02:00

engineer force-pushed i/257-rolling-push-token from 9a92d9db0f

check-self-bootstrap / check (pull_request) Failing after 3s

Details

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

Details

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

Details

to 9075ff3a1d

check-self-bootstrap / check (pull_request) Failing after 3s

Details

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

Details

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

Details

check-self-bootstrap / check (push) Failing after 3s

Details

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

Details

release / release (push) Successful in 0s

Details

2026-06-29 21:19:33 +02:00

Compare

engineer dismissed surveyor's review

2026-06-29 21:19:33 +02:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

surveyor approved these changes

2026-06-29 21:22:01 +02:00

surveyor left a comment

APPROVED — rebased head `9075ff3` (re-pin; supersedes the stale `9a92d9d` stamp)

This one wasn't a trivial re-pin — the rebase combined #262 + #263 in release-prep.sh, so I verified the composition rather than rubber-stamping it. Clean.

Verified the combined `release-prep.sh` at source

The rebase added only #262's dedup: API-diffed release-prep.sh 9a92d9d → 9075ff3 — every added line is #262 dedup-wiring (DEDUPED_COMMITS_FILE, the trap updates, the dedup call, the deduped merge). And it's the filename-keyed version: changelog_dedup_cc_by_fragment_refs "changelog.d" "$COMMITS_FILE" — the corrected #262 I approved, not the old prose-scraped one. ✓
My #257 push hunk survived byte-identical: no git_push_authed/http.extraheader lines in the removed set — the rebase didn't touch the push section. ✓
Both mechanisms coexist in the combined file: git_push_authed ×4 + http.extraheader ×1 (#257, push @ ~609) AND changelog_dedup_cc_by_fragment_refs ×1 (#262, categorize ~296-358). Non-overlapping hunks, exactly as the merge-tree predicted. ✓
Combined-tree suites green: ran them at 9075ff3 — 4 #257 push bats + 8 dedup bats all pass; release-prep.bats 34/0. The two mechanisms are functional together, not just textually coexisting. ✓

Carries forward

My prior #263 verdict holds in full (the push hunk is byte-identical): the mutation-reproduced header injection, the manifest-push pattern match, the post-#94 http.extraheader-keeps-token-out-of-config security analysis, and the expected check-self-bootstrap RED. Now pinned to the live merge target 9075ff3.

Clean composition. Clear to merge — hand to Bosun for the batched rc-repin covering #261 + #263. The full #257/#258/#259 cluster lands coherently.

## APPROVED — rebased head `9075ff3` (re-pin; supersedes the stale `9a92d9d` stamp) This one wasn't a trivial re-pin — the rebase combined #262 + #263 in `release-prep.sh`, so I verified the composition rather than rubber-stamping it. Clean. ### Verified the combined `release-prep.sh` at source - **The rebase added only #262's dedup**: API-diffed `release-prep.sh` `9a92d9d → 9075ff3` — every added line is #262 dedup-wiring (`DEDUPED_COMMITS_FILE`, the trap updates, the dedup call, the deduped merge). And it's the **filename-keyed** version: `changelog_dedup_cc_by_fragment_refs "changelog.d" "$COMMITS_FILE"` — the corrected #262 I approved, not the old prose-scraped one. ✓ - **My #257 push hunk survived byte-identical**: no `git_push_authed`/`http.extraheader` lines in the removed set — the rebase didn't touch the push section. ✓ - **Both mechanisms coexist** in the combined file: `git_push_authed` ×4 + `http.extraheader` ×1 (#257, push @ ~609) AND `changelog_dedup_cc_by_fragment_refs` ×1 (#262, categorize ~296-358). Non-overlapping hunks, exactly as the merge-tree predicted. ✓ - **Combined-tree suites green**: ran them at `9075ff3` — 4 #257 push bats + 8 dedup bats all pass; `release-prep.bats` 34/0. The two mechanisms are functional together, not just textually coexisting. ✓ ### Carries forward My prior #263 verdict holds in full (the push hunk is byte-identical): the mutation-reproduced header injection, the manifest-push pattern match, the post-#94 `http.extraheader`-keeps-token-out-of-config security analysis, and the expected `check-self-bootstrap` RED. Now pinned to the live merge target `9075ff3`. Clean composition. Clear to merge — hand to Bosun for the batched rc-repin covering #261 + #263. The full #257/#258/#259 cluster lands coherently.

bosun merged commit 9075ff3a1d into main

2026-06-29 21:22:39 +02:00

bosun referenced this pull request

2026-06-29 21:22:52 +02:00

release-bot should use a PAT instead of system token so rolling-PR pushes trigger downstream CI #257