-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(platform/gitlab): stabilize PR/MR auto-merge for Gitlab #27356
feat(platform/gitlab): stabilize PR/MR auto-merge for Gitlab #27356
Conversation
@javaxiss could you take a look if you have time? |
@viceice : All comments are resolved. Is there anything else left or can we get this PR merged? |
yes, failed tests. |
The failing test is totally unrelated to my changes. It's located in
My PR doesn't introduce any config or PGP related changes. Furthermore, all tests are locally green. Especially the one raised by the build pipeline. |
I've updated the branch from main again to see the results |
It's passing now |
Head branch was pushed to by a user without write access
@viceice would you mind re-approving the MR? Thanks! :) |
🎉 This PR is included in version 37.209.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Changes
This change is only related to the auto-merge functionality of the Gitlab platform.
Before executing the auto-merge the code checks for various statuses to reduce the number of retries and thus lowering the waiting time.
The actual call to enable auto-merge is now covered by a retry logic. This is needed, because Gitlab sometimes responds with a "405 method not allowed" even though the merge request status is already proposing a merge-able status. The time to consistency window seems to vary depending on the actual load of the Gitlab instance.
The change removes the hard coded check for the Gitlab version introduced with #26438.
merge_status
is deprecated with Gitlab 15.6 and will be removed sooner or later in favor ofdetailed_merge_status
. Hence,detailed_merge_status
should be preferred if available.Context
I'm executing Renovate Bot across ~150 repos and observed many unmerged merge requests even though the build succeeded. With a high change rate of the libraries, the MRs tend to stay open for too long. Hence, I wanted to improve the stability of the auto-merge with the current Renovate Bot run.
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: