uros-b opened a new pull request, #57959:
URL: https://github.com/apache/spark/pull/57959
### What changes were proposed in this pull request?
This PR changes how `dev/merge_spark_pr.py` handles a committer declining to
resolve a conflicting backport cherry-pick.
Previously, when a cherry-pick onto a maintenance branch conflicted, the
script prompted `Would you like to manually fix-up this merge?`. Answering `N`
went through `continue_maybe(..., cherry=True)`, which aborted the cherry-pick
and then called `fail("Okay, exiting")` — terminating the whole run via
`sys.exit(-1)`. As a result the committer never reached the JIRA-resolution
step, and the process exited non-zero, even though the merge into the target
branch (and any earlier cherry-picks) had already been pushed.
This PR makes declining a cherry-pick fix-up skip only that one branch and
continue:
- Add a `SkipCherryPick` exception. When a cherry-pick fix-up prompt is
declined, `continue_maybe` aborts the cherry-pick, restores the working tree
(`clean_up()`), and raises `SkipCherryPick` instead of calling `fail()`.
- `cherry_pick()` catches `SkipCherryPick` and returns only the picks that
actually landed (empty, or — in the Upstream-First two-branch path — just the
sibling branch that was already pushed).
- The two merge/backport loops in `main()` already consume the returned list
generically (`merged_refs + []` is a no-op), so no loop changes are needed:
after a skip they simply offer the next branch and still proceed to resolve the
associated JIRA.
Hard aborts elsewhere are unchanged (e.g. declining the push prompt, or
choosing `[a]bort` at the Upstream-First prompt, still exit).
### Why are the changes needed?
Backport cherry-pick conflicts are routine, and by the time one occurs the
merge into the target branch has already been pushed. Aborting the entire
script on a declined fix-up means the committer:
- skips JIRA resolution (the ticket is left Open, which is easy to miss and
tedious to reconcile after the fact), and
- gets a non-zero exit for what is a normal "do not backport that one
branch" decision.
Declining a single conflicting backport should skip just that branch and let
the merge finish cleanly.
### Does this PR introduce _any_ user-facing change?
No. This changes a committer-only developer tool (`dev/merge_spark_pr.py`);
it is not part of any Spark release artifact.
### How was this patch tested?
- The module's inline doctests still pass (run by `doctest.testmod()` at
startup): 76 attempted, 0 failed.
- `python3 -m py_compile dev/merge_spark_pr.py` is clean.
- Manually traced the affected control-flow paths:
- single-branch pick declined -> `cherry_pick` returns `[]`, the loop
re-prompts and JIRA resolution still runs;
- Upstream-First `[b]oth` path with the second pick declined -> the
already-pushed sibling branch is still returned and recorded in the merge
comment / `merged_refs`;
- declining non-cherry prompts, and `[a]bort` at the Upstream-First
prompt, still hard-exit as before.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code with Claude Opus 4.8
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
