feat(azure): add support for rebase-merge #33732
Open
+15
−1
Conversation
This file contains 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
Azure DevOps has support for semi-linear rebase (rebase with merge commit, see [1]). Our branch policies enforce this option, which is incompatible with any of the `automergeStrategy` options currently available. In fact, when this option is set to auto, Renovate Bot will actually select semi-linear rebasing if that is the only option. But if there are other (allowed) options, then there is nothing to enforce it. This adds the `rebase-merge` option, which is different from using `rebase` (again, see [1]). Based on closer inspection, I see that Gitea will do a rebase with merge when the option is `rebase`. I did not adapt this, because that would break current configurations. Also, I only have the option to test this with Azure DevOps. [1]: https://devblogs.microsoft.com/devops/pull-requests-with-rebase/
rarkins
requested changes
Jan 22, 2025
| @@ -263,6 +263,7 @@ You may choose from these values: | |||
| - `fast-forward`, "fast-forwarding" the main branch reference, no new commits in the resultant tree | |||
| - `merge-commit`, create a new merge commit | |||
| - `rebase`, rewrite history as part of the merge, but usually keep the individual commits | |||
| - `rebase-merge`, create a new merge commit, but rebase the commits prior merging | |||
There was a problem hiding this comment.
Note here that it's Azure-only
viceice
requested changes
Jan 22, 2025
|
@viceice Thank you for the review. Happy to make the requested changes, but any advice on how to deal with Gitea? Like mentioned in the PR and commit, I saw that Gitea will use rebase-merge if the So technically, it is not an Azure DevOps specific feature, as requested. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Changes
Azure DevOps has support for semi-linear rebase (rebase with merge commit, see 1). Our branch policies enforce this option, which is incompatible with any of the
automergeStrategyoptions currently available.In fact, when this option is set to auto, Renovate Bot will actually select semi-linear rebasing if that is the only option. But if there are other (allowed) options, then there is nothing to enforce it.
This adds the
rebase-mergeoption, which is different from usingrebase(again, see 1).Based on closer inspection, I see that Gitea will do a rebase with merge when the option is
rebase. I did not adapt this, because that would break current configurations. Also, I only have the option to test this with Azure DevOps.Context
I could not get automerge to work, until I found out that the
rebaseoption does not map to semi-linear rebase within Azure DevOps. This silently fails when a PR gets created.Given that rebase-merge is rebase + merge combined, this option makes sense.
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: