fix(publish): make post-publish merge failure non-fatal with resolve strategy retry#778
Merged
fix(publish): make post-publish merge failure non-fatal with resolve strategy retry#778
Conversation
…strategy retry When all publish targets succeed but the subsequent merge of the release branch back into the default branch fails (e.g., due to a CHANGELOG.md conflict), the entire publish command would exit with code 1 — even though all irreversible publishing operations completed successfully. This caused the publish workflow to report failure, leave the publish issue open, skip the post-release command, and leave the release branch unmerged. Changes: - Break the chained pull().merge().push() into separate calls so merge failures can be caught and retried independently - On merge failure with the default strategy (ort), abort and retry with -s resolve which handles criss-cross merge ambiguities differently and often succeeds where ort fails - If both strategies fail, catch the error in publishMain(), report to Sentry via captureException, log a warning with manual resolution instructions, but still exit successfully since all targets published - State file cleanup and post-release command now always run regardless of merge outcome - Export handleReleaseBranch for testability Fixes: getsentry/publish#7519
![sentry[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
itaybre
reviewed
Mar 18, 2026
- Wrap git pull --rebase in try/catch with git rebase --abort cleanup so a failed rebase doesn't leave the repo in an active rebase state - Wrap resolve strategy retry in try/catch with git merge --abort so a failed resolve merge also leaves the repo clean - Replace hardcoded 'origin' with argv.remote in manual resolution instructions (supports non-default remotes) - Add test for rebase abort on pull failure - Update both-strategies-fail test to verify second merge --abort
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When all publish targets succeed but the subsequent merge of the release branch back into the default branch fails (e.g., due to a CHANGELOG.md conflict), the entire
craft publishcommand exits with code 1 — even though all irreversible publishing operations completed successfully.This caused the publish workflow to report failure, leave the publish issue open, skip the post-release command, and leave the release branch unmerged and undeleted.
Observed in: getsentry/publish#7519 ([email protected])
Fix
Part 1 — Retry with
resolvestrategy: Breaks the chainedpull().merge().push()into separate calls. When the default merge strategy (ort) fails, the function aborts the merge and retries with-s resolve, which uses a simpler 3-way merge algorithm that handles criss-cross ambiguities differently.Part 2 — Non-fatal error handling: If both strategies fail, the error is caught in
publishMain(), reported to Sentry viacaptureException, and a warning with manual resolution instructions is logged — but the command still exits successfully since all targets published. State file cleanup and the post-release command always run regardless of merge outcome.Test plan
handleReleaseBranchcovering: default merge success, resolve retry on conflict, abort failure tolerance, both-strategies-fail propagation, branch deletion, keepBranch, and default branch resolution