publish: Give a recovery path when the release branch can't be merged back #966

When craft publish can't merge the release branch back, it leaves the branch unmerged and skips postReleaseBump. Its manual steps ("merge the release branch into the target branch, then delete it") don't work on a repo that only allows squash merges for PRs.

What happened

The toolkit cli/0.48.0 publish (job log) shipped every target, then hit MergeConflictError on references/init.md. #964 now resolves that kind of conflict, which only touches the version line. Any other conflict still ends up here.

Recovering by hand took several steps:

1. Merge release/cli/0.48.0 into main locally, resolve the conflict, and run the postReleaseBump changes by hand. That is the dev version bump, and Craft logs no hint that it was skipped.
2. Open a PR with that merge commit (meta: Merge release/cli/0.48.0 back into main toolkit#2027).
3. Find out the PR can't merge. getsentry/toolkit only allows squash merges, and a squash drops the second parent, so cli@0.48.0 is no longer reachable from main. getLatestTag uses git describe, so the next prepare would compute 0.48.0 again. getChangelogBaseTag would also start the changelog at 0.47.0 and repeat every 0.48.0 entry.
4. Push the merge commit to main directly, which needs someone who can bypass the branch ruleset. The release bot can bypass it, which is why a normal merge-back works.

Suggested fixes

Any of these would help:

• Retry only the merge-back. For example, a craft publish --merge-only (or a separate subcommand) that skips the targets and runs the merge, postReleaseBump, the push and branch cleanup with the release bot's credentials. Then someone fixes the conflict on the release branch, or on the target branch, and re-runs the merge step instead of doing it by hand.
• Better failure output. The MergeConflictError message should say:
  • the result must be a real merge commit (no squash, no rebase), or the next release can't find the tag
  • postReleaseBump was skipped and needs to run too
  • which command reruns it
• Fail early on squash-only repos. Warn during prepare or publish, so people learn the PR route won't work before a release is half done.

Related

• fix(publish): Resolve merge conflicts caused only by the version bump #964 handles conflicts that only touch the version line, so this case is now rarer.
• fix(targets): Wait for npm before publishing to the MCP Registry #963 handles the npm propagation delay that failed the first 0.48.0 publish at the MCP Registry target.

via @BYK.

--

View Session in Sentry