Enable rebuild+backport MR consolidation#689
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a new feature to consolidate rebuild MRs (ymir_rebuild) into backport MRs (ymir_backport) to avoid redundant Release bumps. It adds a new rebuild_append_flow that cherry-picks the backport branch and appends rebuild Jira tickets and CVEs to the commit message and changelog. The review feedback highlights two critical issues: first, if the backport branch has no new commits, the flow will dangerously amend an already merged commit on the main branch; second, if multiple Jira issues resolve to the same MR, the agent may attempt to consolidate an MR with itself due to duplicate entries in matched_mrs.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
PR Summary by QodoEnable backport+rebuild MR consolidation with append-only commit metadata
AI Description
Diagram
High-Level Assessment
Files changed (5)
|
7db815e to
e813c60
Compare
Code Review by Qodo
Context used✅ Compliance rules (platform):
7 rules 1. Retry re-cherry-picks commits
|
| def _retry_step_for_build(state): | ||
| """Determine which flow to retry on build failure.""" | ||
| has_rebuild_other = any(t == "rebuild" for t in state.mr_types.values()) | ||
| if has_rebuild_other and len(state.mr_types) > 1: | ||
| return "rebuild_append_flow" | ||
| if release_strategy == "per_commit": | ||
| return "per_commit_flow" | ||
| return "run_consolidation_agent" | ||
|
|
||
| try: | ||
| build_result = await build_agent.run( | ||
| build_prompt, |
There was a problem hiding this comment.
2. Retry re-cherry-picks commits 🐞 Bug ☼ Reliability
On build verification failure, the retry logic routes backport+rebuild consolidations to rebuild_append_flow, which cherry-picks the same base commits again without resetting the repo. This makes retries likely to fail (empty/duplicate cherry-picks) and prevents meaningful recovery.
Agent Prompt
### Issue description
`run_build_agent` retries by re-entering `rebuild_append_flow` for backport+rebuild scenarios, but `rebuild_append_flow` is not idempotent: it cherry-picks `dist_git_branch..base_branch` into the same working tree again. On the second attempt, those commits are already applied, so `git cherry-pick` is prone to failing (empty cherry-picks / conflicts), making retries ineffective.
### Issue Context
- Retries happen within the same workflow run and reuse `state.local_clone`.
- `rebuild_append_flow` does not perform any cleanup (`reset --hard`, `clean -fdx`, `cherry-pick --abort`) before applying commits.
### Fix Focus Areas
- Before starting `rebuild_append_flow`, ensure the repo is reset to a clean base (e.g., `git cherry-pick --abort || true`, `git reset --hard <dist_git_branch>`, `git clean -fdx`).
- Alternatively, change `_retry_step_for_build` so build failures after append flow do not retry append flow (e.g., fall back to `run_consolidation_agent` or re-run `fork_and_prepare_dist_git` to get a fresh clone).
- ymir/agents/mr_consolidation_agent.py[634-677]
- ymir/agents/mr_consolidation_agent.py[998-1037]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| return _retry_step_for_build(state) | ||
| return "handle_failure" | ||
|
|
||
| if release_strategy == "per_commit": |
There was a problem hiding this comment.
1. Release bump in append 🐞 Bug ≡ Correctness
When rebuild_append_flow is used and release_strategy != "per_commit" (i.e., "merged"), run_build_agent routes to update_release, causing a second Release bump even though the base backport already bumped Release. This violates the intended append-only behavior and can produce an unexpected NVR.
Agent Prompt
### Issue description
`rebuild_append_flow` is explicitly designed to avoid a second Release bump (the backport MR already bumped Release). However, after build verification, `run_build_agent` returns `update_release` for non-`per_commit` strategies, which reintroduces an extra Release bump in the append flow.
### Issue Context
- `fork_and_prepare_dist_git` routes to `rebuild_append_flow` when there is exactly one backport MR and the other MR(s) are rebuild.
- `rebuild_append_flow` cherry-picks the backport branch and skips rebuild cherry-picks specifically to avoid redundant Release bumps.
- The workflow still calls `update_release` afterward when `release_strategy == "merged"`.
### Fix Focus Areas
- Ensure append flow does not call `update_release` regardless of `release_strategy` (e.g., set a state flag like `state.skip_release_bump=True` in `rebuild_append_flow`, or return directly to `push_and_open_mr` after successful build verification).
- Keep behavior unchanged for existing non-append flows.
- ymir/agents/mr_consolidation_agent.py[520-590]
- ymir/agents/mr_consolidation_agent.py[634-682]
- ymir/agents/mr_consolidation_agent.py[998-1182]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
e813c60 to
faafae6
Compare
The consolidation agent now discovers both ymir_backport and ymir_rebuild MRs. When a package has one backport and one rebuild MR open for the same branch, the rebuild is folded into the backport via an append-only flow: the backport branch is cherry-picked as base and the rebuild ticket(s) plus CVEs are appended to the commit message without a second Release bump. Selection priority: backport+backport pairs are still consolidated first; backport+rebuild only when fewer than 2 backport MRs exist. The rebuild agent now submits a consolidation job after creating its MR (same mechanism as the backport agent), so the consolidation agent can pick up both MR types on the next queue poll. CVE handling: CVE IDs are extracted from both MR descriptions and merged into the consolidated commit only if the base backport already included a CVE: line (respecting per-package maintainer rules). Assisted-by: Claude Opus 4.6 (Cursor)
Extract the duplicated fetch-config/check-enabled/submit-to-Redis logic from both backport_agent and rebuild_agent into a single try_submit_consolidation_job() function in tasks.py. Each agent keeps its own thin wrapper for precondition checks and error handling (backport posts a Jira comment on malformed config, rebuild just logs). Co-authored-by: Cursor <cursoragent@cursor.com>
4f258c3 to
7579fcc
Compare
The consolidation agent now discovers both ymir_backport and ymir_rebuild MRs. When a package has one backport and one rebuild MR open for the same branch, the rebuild is folded into the backport via an append-only flow: the backport branch is cherry-picked as base and the rebuild ticket(s) plus CVEs are appended to the commit message without a second Release bump.
Selection priority: backport+backport pairs are still consolidated first; backport+rebuild only when fewer than 2 backport MRs exist.
The rebuild agent now submits a consolidation job after creating its MR (same mechanism as the backport agent), so the consolidation agent can pick up both MR types on the next queue poll.
CVE handling: CVE IDs are extracted from both MR descriptions and merged into the consolidated commit only if the base backport already included a CVE: line (respecting per-package maintainer rules).
Assisted-by: Claude Opus 4.6 (Cursor)