backport: prepare shared modules and source-change planning - #81
backport: prepare shared modules and source-change planning#81sarthakaggarwal97 wants to merge 2 commits into
Conversation
…ules Mechanical preparation for unifying the manual and sweep apply engines: - git_commands.py: run_git (was main._run_git), has_staged_changes, index_stage_exists, read_index_stage (were sweep_apply) moved verbatim. Breaks the sweep_apply -> main import edge. - missing_test_adaptation.py: the test-adaptation half of sweep_apply.py moved verbatim (sandbox, snapshots, prompt, import/restore machinery). - extract_agent_result_text: two near-identical copies (sweep_apply, sweep_validation) deduplicated into scripts/ai/runtime.py, which owns the stream-JSON result format. - Dead code removed: the source PR diff fetch in main.py and the BackportPRContext.source_pr_diff field it fed (nothing ever read it), and diff_comments.list_marked_source_prs (only tests called it). No behavior change. Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>
Classify how a merged PR landed (merge / squash / single) and pin the one authoritative commit that carries its complete change. Rebase merges fail closed: their merge SHA is only the final rewritten commit, and replaying a rebased series is unsupported, so those PRs must be backported manually. Squash-vs-rebase discrimination compares exact patch identities (git patch-id --verbatim over a binary --full-index diff) between the merge SHA and the source series. Ambiguous or disconnected histories are refused rather than guessed at. Incomplete commit listings (the API pages out on very large PRs) fall back to fetching the authoritative PR head. Real-Git contract tests cover every classification and refusal path. Nothing consumes the module yet; the apply engines switch over next. Signed-off-by: Sarthak Aggarwal <sarthagg@amazon.com>
|
Warning Review limit reached
Next review available in: 34 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (16)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
This is prep work for sharing one backport engine between the manual and scheduled flows.
It moves the shared Git helpers and missing-test adaptation into their own modules, removes the unused source-PR diff fetch, and consolidates the result parser used by the sweep paths.
It also adds source-change planning. This identifies the single commit representing a merged PR for merge, squash, and single-commit cases. Multi-commit rebase merges stop with a clear manual-backport message because GitHub’s merge SHA contains only the final rewritten commit.