-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix(gerrit): not auto-merging if Code-Review changed from +2 to +1 #32818
base: main
Are you sure you want to change the base?
Conversation
5b42180
to
4028843
Compare
4028843
to
06ecde1
Compare
06ecde1
to
46f8eed
Compare
82fe8e1
to
107a298
Compare
dcc53d7
to
6ac7b9e
Compare
4817e82
to
6ffa5b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conflicted
…ix-auto-merge-if-plus-one
I just realized this function is also implemented by the GitLab provider, and there it doesn't check for whether it's approved already or not, meaning it will probably issue an error, which is not desired. I'll think about it. |
56bd600
to
761106b
Compare
761106b
to
45763e9
Compare
I've refactored the other two platforms (Azure and GitLab) that also use
Note I do not use Azure or GitLab. I coded these functions based on their documentation. But I believe there is no big risk involved, given it will still attempt to auto-approve in case the is approved condition doesn't match. |
45763e9
to
5a0955c
Compare
5a0955c
to
ab9907a
Compare
I've retitled the PR to reflect the broader impact of it. |
ab9907a
to
c679c28
Compare
if (config.autoApprove && platform.approvePr) { | ||
logger.debug('Auto-approving PR if needed before automerge'); | ||
await platform.approvePr(pr.number); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this cause each PR to be approved on each run? i.e. one extra API call per PR per run?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this cause each PR to be approved on each run?
Only if the PR is not yet approved. I implemented all approvePr
functions to account for this case.
i.e. one extra API call per PR per run?
Per auto-merge attempt, there will be one extra API call to verify whether the PR is not yet approved, and one more API call to approve it in case it's not yet approved.
Just remember:
- this is only applicable for azure, gitlab, and gerrit
- and for people who have
autoApprove: true
- and all other conditions in
automerge.ts
already passed (exceptbranchStatus
, which depends on the approval to be green)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if you believe it's not a good idea, I can find another way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly it could be optimized so that it doesn't perform this "is the PR already approved?" check right after we create the PR? i.e. because we know it's impossible that we approved it already.
if (config.autoApprove && platform.approvePr) { | ||
logger.debug('Auto-approving PR if needed before automerge'); | ||
await platform.approvePr(pr.number); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly it could be optimized so that it doesn't perform this "is the PR already approved?" check right after we create the PR? i.e. because we know it's impossible that we approved it already.
@rarkins, it's presumptuous from my part that this would be of any help to the existing platforms. I will revert the changes to Azure and GitLab, and focus on Gerrit, which is what I use and know this would make sense for. |
const changes = await this.gerritHttp.getJson<GerritChange>( | ||
`a/changes/${changeNumber}?` + | ||
this.requestDetails.map((det) => `o=${det}`).join('&'), | ||
`a/changes/${changeNumber}?` + options.map((det) => `o=${det}`).join('&'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use getQueryString
for proper quoting
Line 72 in 2f49607
export function getQueryString(params: Record<string, any>): string { |
change.labels?.['Code-Review'].approved && | ||
change.labels['Code-Review'].approved.username === username | ||
reviewLabel === undefined || | ||
Boolean(reviewLabel.all?.some((label) => label.value === 2)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Boolean(reviewLabel.all?.some((label) => label.value === 2)) | |
reviewLabel.all?.some((label) => label.value === 2) === true |
config.autoApprove = true; | ||
config.automerge = true; | ||
config.pruneBranchAfterAutomerge = true; | ||
platform.approvePrForAutomerge.mockResolvedValueOnce(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
platform.approvePrForAutomerge.mockResolvedValueOnce(); |
not needed, default for a mock
Changes
The
checkIfApproved
function was not working as expected when someone already had published a Code-Review +1 vote. It was wrongly assuming that the change was approved in such case, while the change should only be approved if the change had a Code-Review +2 vote.Note that when
o=DETAILED_LABELS
is set, the change response from Gerrit API no longer contains the content fromo=LABELS
, meaning it should only ever be used in this case (when looking for the approvals), otherwise it would break existing code.This fix also ensures that the change will be auto-approved again during the auto-merge process, it case the Code-Review +2 was changed to +1 by some CI check using the same account as Renovate, like SonarQube (which posts Code-Review +1).
Finally, this fix will improve the approval logic for when the change is initially created or updated. It will avoid two API calls in each case.
Context
I self-host Renovate and I noticed that auto-merge was not working as expected. I realized it was caused by this issue, because for a given project we have here, the same user/robot also votes the change with a Code-Review +1 vote when SonarQube analysis is successful (which is a very known pattern).
Documentation (please check one with an [x])
How I've tested my work (please select one)
I have verified these changes via: