chore(renovate-preset): rebase on conflict DEVX-659#78
Conversation
**WHY** Numerous renovate PRs remain unmerged for days, weeks or even months. Renovate would rebase these branches whenever it detects they are behind the default branch causing another CI run. This causes high load on our CI infrastructure without much benefit. Many repositories do not require a linear history yet and thus don't need to be keep up-to-date. There is a risk to this since incompatibilities might go unnoticed, but this is true for any change in such a context. Midterm DevX team butterfly plans to require linear history for all repositories which requires a merge queue to work efficiently. The change has been tested in some repositories including product-analytics-pipeline where it reduce the shared of CI runs caused by renovate from 67% to 9%. **WHAT** Renovate preset adjusted so renovate would rebase only if it detects merge conflicts between default and feature branch.
r0binary-sap
requested review from
StefanKuerten1234,
kostas-petrakis,
liudmyla-b and
timovankissing-leanix
|
📊 Survey: Please help us track internal AI adoption. This is not for evaluation, only for metrics. You can update this anytime before merge.
🧑💻 If AI was used, what was it mainly used for?
Thank you in advance for your feedback.💙🙏🎉 |
SummaryThe following content is AI-generated and provides a summary of the pull request: chore: Configure Renovate to Rebase Only on Merge ConflictsChore🔧 Adjusted the Renovate preset to trigger branch rebases only when merge conflicts are detected, rather than rebasing whenever a branch falls behind the default branch. Previously, Renovate would rebase feature branches any time they were behind the default branch, causing unnecessary CI runs. This change reduces CI load significantly — in tested repositories like Changes
Jira Issues
PR Bot InformationVersion:
💌 Have ideas or want to contribute? Create an issue and share your thoughts with us! Made with ❤️ by Hyperspace. |
![hyperspace-insights[bot]](https://avatars.githubusercontent.com/u/2531208?s=60&v=4){kind=small}
There was a problem hiding this comment.
The change is a single, straightforward configuration addition. The value "conflicted" is the correct valid Renovate option for rebaseWhen, the JSON is well-formed, and the placement is appropriate. There are no logic errors, bugs, typos, or other issues to flag.
The PR is a clean, minimal configuration change that correctly implements the described behaviour — limiting Renovate rebases to only conflict situations, which aligns with the stated goal of reducing unnecessary CI runs.
PR Bot Information
Version: 1.20.11 | 📖 Documentation | 🚨 Create Incident | 💬 Feedback
- Correlation ID:
be704474-5af8-4029-9abf-ac6a59f2fb1c - LLM:
anthropic--claude-4.6-sonnet - File Content Strategy: Full file content
- Event Trigger:
pull_request.opened
r0binary-sap
deleted the
feature/DEVX-659-renovate-preset-rebase-on-conflict-only
branch
2 participants
WHY Numerous renovate PRs remain unmerged for days, weeks or even months. Renovate would rebase these branches whenever it detects they are behind the default branch causing another CI run. This causes high load on our CI infrastructure without much benefit. Many repositories do not require a linear history yet and thus don't need to be keep up-to-date. There is a risk to this since incompatibilities might go unnoticed, but this is true for any change in such a context. Midterm DevX team butterfly plans to require linear history for all repositories which requires a merge queue to work efficiently. The change has been tested in some repositories including product-analytics-pipeline where it reduce the shared of CI runs caused by renovate from 67% to 9%.
WHAT Renovate preset adjusted so renovate would rebase only if it detects merge conflicts between default and feature branch.