What would you like to be added:
A --rerun mode for krel release-notes that allows re-running against an existing draft PR branch, with full control over which fork/branch to fetch from and optionally push to.
New flags:
--rerun # enter rerun mode (mutually exclusive with --create-draft-pr)
--draft-pr-source-fork=org[/repo] # which fork to fetch the existing branch from (required)
--draft-pr-source-branch=name # branch to fetch (default: release-notes-draft-<tag>)
--draft-pr-push-fork=org[/repo] # where to push results (optional — omit to work locally)
--draft-pr-push-branch=name # branch name on push destination (default: source branch)
High-level flow:
FIRST RUN (today) RERUN (proposed)
┌──────────────────────┐ ┌───────────────────────────────────┐
│ --create-draft-pr │ │ --rerun │
│ --fork=me │ │ --draft-pr-source-fork=colleague │
│ --tag=v1.36.0-beta.0 │ │ --tag=v1.36.0-beta.0 │
└──────────┬───────────┘ │ --maps-from=./maps │
│ │ --draft-pr-push-fork=me (optional)│
▼ └──────────┬────────────────────────┘
clone k/sig-release │
branch off HEAD ▼
generate notes clone k/sig-release
push to fork fetch source branch from colleague's fork
create PR apply --maps-from overrides
cleanup tmp dir regenerate .md + .json
optionally push to my fork
preserve local clone for inspection
Why is this needed:
Today, after the initial krel release-notes --create-draft-pr run creates a PR against k/sig-release, reviewers suggest changes to the .md file. The author then needs to create map files and re-run krel with --maps-from to incorporate those suggestions — but krel fails on re-run because VerifyFork rejects the operation when the branch already exists on the fork:
Error: a branch named release-notes-draft-v1.36.0-beta.0 already exists in <user>/sig-release
There is no way to point krel at an existing branch. This forces a fully manual workflow for post-review updates (manually creating and editing maps, syncing those changes to .json & .md files manually, committing, and pushing by hand).
The problem is compounded when a different team member needs to pick up the rerun work --> there's no way to fetch a colleague's draft branch, apply maps, and push to one's own fork.
--maps-from already supports syncing map file overrides into .json and .md, so the generation machinery is in place. What's missing is the ability to:
- Skip the branch-existence gate (
VerifyFork) when rerunning
- Fetch an existing branch from any fork instead of always branching off upstream HEAD
- Decouple source and destination i.e. fetch from fork A, push to fork B (or don't push at all)
- Preserve the local clone for inspection since no PR is being created
All changes would live in cmd/krel/cmd/release_notes.go — no modifications to release-sdk required. The rerun path would call lower-level SDK primitives (git.CleanCloneGitHubRepo, repo.AddRemote, repo.Checkout) directly, bypassing VerifyFork and PrepareFork.
What would you like to be added:
A
--rerunmode forkrel release-notesthat allows re-running against an existing draft PR branch, with full control over which fork/branch to fetch from and optionally push to.New flags:
High-level flow:
Why is this needed:
Today, after the initial
krel release-notes --create-draft-prrun creates a PR againstk/sig-release, reviewers suggest changes to the.mdfile. The author then needs to create map files and re-run krel with--maps-fromto incorporate those suggestions — but krel fails on re-run becauseVerifyForkrejects the operation when the branch already exists on the fork:There is no way to point
krelat an existing branch. This forces a fully manual workflow for post-review updates (manually creating and editing maps, syncing those changes to.json&.mdfiles manually, committing, and pushing by hand).The problem is compounded when a different team member needs to pick up the rerun work --> there's no way to fetch a colleague's draft branch, apply maps, and push to one's own fork.
--maps-fromalready supports syncing map file overrides into.jsonand.md, so the generation machinery is in place. What's missing is the ability to:VerifyFork) when rerunningAll changes would live in
cmd/krel/cmd/release_notes.go— no modifications torelease-sdkrequired. The rerun path would call lower-level SDK primitives (git.CleanCloneGitHubRepo,repo.AddRemote,repo.Checkout) directly, bypassingVerifyForkandPrepareFork.