Pre-merge cherry-pick flow for patch-labeled PRs

[kriszyp]

Summary

Two changes to the patch-release pipeline:

1. Bug fix in scripts/patch-release.js: the script computed the next-version target by reading package.json from the working tree (typically main), so the proposed version was based on main's version, not the release branch's. Now reads via git show origin/<release>:package.json so the target is calculated against the correct baseline.

2. New pre-merge cherry-pick flow (replaces the post-merge flow):

   • On pull_request labeled patch (and on synchronize while labeled): create/reset cherry-pick/<release>/pr-<N> off the release branch, cherry-pick the PR commits, force-push.
   • On success: dispatch the existing integration-tests.yaml workflow against that branch. A sticky comment on the original PR links the run.
   • On conflict: commit the markers, push, and post a sticky comment that @claude to suggest a resolution patch as a comment (no auto-push).
   • On unlabeled: delete the branch and mark the sticky cancelled.
   • On closed && merged: re-pick from the final merge SHA and fast-forward into the release branch.
   • A second workflow (report-cherry-pick-tests.yml) listens to workflow_run completion for Integration Tests and updates the same sticky comment with pass/fail.

This means patch test results show up on the original PR — no separate cherry-pick PR — and we get a pre-merge signal on whether the change is safe against the release branch.

Where to focus review

• .github/workflows/cherry-pick-patch.yml — the main logic. Branches handled in the Cherry-pick step: open PR (merge_base..HEAD) vs merged PR (merge commit with -m 1 if it's a true merge). IS_MERGED is driven by the API's merged field, not the event action, so labeling an already-merged PR still triggers the fast-forward into the release branch.
• report-cherry-pick-tests.yml — gated on head_repository.full_name == github.repository so a fork can't spoof a cherry-pick/... branch name to inject comments. PR number is parsed from the branch name.
• upsert-sticky-comment.js — passes the comment body via stdin (-f body=@-) to avoid shell-escape issues with the multi-line markdown body.
• scripts/patch-release.js — the diff looks huge because prettier converted 2-space indentation to tabs. The only semantic change is the new readPackageVersion(ref) function (around L186) and its two callers passing origin/${RELEASE_BRANCH} (around L280-281).

Things to verify before relying on it

• The conflict path @-mentions @claude in a sticky comment expecting claude-mention.yml to pick it up. If that workflow ignores comments authored by github-actions[bot], the suggestion won't fire; we'd need to call the reusable directly instead.
• gh workflow run followed by short polling for the run id is best-effort — the workflow_run reporter is the source of truth, so a missed initial link is cosmetic.
• The merged-PR fast-forward assumes the cherry-pick branch and the release branch haven't diverged since the last sync; the workflow re-picks from the final merge SHA on a fresh branch before merging, so it should always FF.

🤖 Generated by Claude Opus 4.7 (1M context).

[claude]

Reviewed; no blockers found.