ci(release-plz): prune stale release branches before opening the PR

[AprilNEA]

Problem

release-plz release-pr has been failing with HTTP 422 and the job swallows it as a warning (release-plz release-pr failed with HTTP 422; continuing with no PRs created → {"prs":[]}), so no release PR is created and releases silently stopped (latest tag is still v0.1.2 despite merged feat/fix commits).

Root cause: a leftover release-plz-2026-05-30T18-10-22Z branch from the merged v0.1.1 release PR (#3) — release-plz collides with the stale ref when creating the next release branch/PR.

Fix

Add a prune step to the release-pr job (after minting the GitHub App token, before release-plz release-pr): delete any release-plz-* branch that has no open PR, keeping the active release PR's branch untouched. The pipeline now self-heals instead of needing a manual branch deletion.

Merging this to master re-triggers release-plz with the prune step, which should clear the stale branch and finally open the pending release PR.

Note

The pending release will be computed by release-plz from conventional commits — with the feat(gui) commits since 0.1.2 that's a 0.2.0 (minor) bump, not 0.1.3. Version decision to be made on the release PR it opens.

[pullfrog]

✅ No new issues found.

Reviewed changes — a one-step prune of stale release-plz-* branches added to the release-pr job so a leftover ref from a merged release PR can't keep release-plz failing with HTTP 422.

• Prune step before release-plz release-pr — iterates every release-plz-* branch returned by gh api repos/$REPO/branches --paginate, deletes any without an open PR, and downgrades DELETE failures to ::warning::. The active release PR's branch is preserved by the open-PR guard.

ℹ️ The swallowed HTTP 422 is the deeper failure mode

This PR fixes the specific 422 trigger (stale branch) but the underlying reason releases stopped silently is that the release-plz action treats release-pr HTTP 422 as a warning and returns {"prs":[]}. The next time a different glitch produces a 422 (or any other non-fatal-to-the-action error path), releases will silently stall again and the symptom will look identical to a quiet week of commits.

Worth a follow-up — e.g. a post-step that fails the job if the action reported no PR created and there are unreleased conventional commits on master. Out of scope for this PR; flagging so it doesn't get lost.

ℹ️ Hardcoded release-plz- prefix vs. configurable pr_branch_prefix

release-plz.toml does not currently set pr_branch_prefix, so the default release-plz- prefix matches the grep here. If that ever gets customized, the prune step will silently skip branches and the original failure mode returns. Not worth fixing today — just worth a note next to the grep, or a comment in release-plz.toml reminding future-you to update the workflow grep if you change the prefix.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}