-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Incorrect GitLab mergeable status determination #1174
Comments
I've done some digging and this appears to be an issue with the GitLab API, or perhaps Atlantis should be checking additional fields in the response JSON. atlantis/server/events/vcs/gitlab_client.go Lines 185 to 187 in 0a67abb
GitLab API response for a non-mergeable MR, https://gitlab.com/rivian/dc/dc-terraform/-/merge_requests/142.
Here's a screenshot of the MR, which shows that it requires two approvals before merging: |
What's the output of your
? |
Hi @lkysow. Thanks for looking into this. The output is part that snippet I shared earlier, it's just difficult to discern. This is the command:
And this is the resulting output:
Looking at the Atlantis code this appears to be sufficient to deem the MR mergeable. That API response is also conflicting with what I see when I look at the same MR via the GitLab UI, which shows it as unmergeable with 2 required approvals before the merge. I reached out to GitLab for clarification, and for the meantime I'm using "approved" status as the apply requirement. |
So approvals before merge is null? Maybe you can just paste the whole api response output? |
Yes, it is null.
|
Is it null for all your pull requests? Maybe gitlab's api has changed? Is it null for PRs that do have enough approvals? |
Yes it's null consistently, even where the two necessary approvals have been met. |
Here is the issue GitLab opened with regard to the API response: https://gitlab.com/gitlab-org/gitlab/-/issues/246991 |
The GitLab issue doesn't look particularly lively. I'm trying to get our account rep to add a "paid customer wants this" status to that issue. In the meantime does Atlantis support a mode where it will apply after merge so the GitLab configuration can be enforced, or perhaps a GitLab version of the Owners policy check? |
So there's a separate API call to check an MR's approval state which looks like it could be used here. https://docs.gitlab.com/ee/api/merge_request_approvals.html#get-the-approval-state-of-merge-requests Response for an an MR requiring 1 approval and is not approved {
"approval_rules_overwritten": false,
"rules": [
{
"id": 12345,
"name": "All Members",
"rule_type": "any_approver",
"eligible_approvers": [],
"approvals_required": 1,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"section": null,
"source_rule": null,
"overridden": false,
"code_owner": false,
"approved_by": [],
"approved": false
}
]
} Response for an MR that is approved, and it looks like it includes the information to support the Owners policy check. {
"approval_rules_overwritten": false,
"rules": [
{
"id": 234,
"name": "All Members",
"rule_type": "any_approver",
"eligible_approvers": [],
"approvals_required": 1,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"section": null,
"source_rule": null,
"overridden": false,
"code_owner": false,
"approved_by": [
{
"id": 1234,
"username": "...",
"name": "Justin Georgeson",
"state": "active",
"avatar_url": "",
"web_url": "https://gitlab.com/..."
}
],
"approved": true
}
]
} |
is this still an issue with |
I think between GitLab releasing 15.x and updates to xanzy-gitlab library this has been resolved. |
Hello,
We have Atlantis set up and configured with gitlab.com. On the repo side I have the apply requirement set to mergeable.
The docs state:
"GitLab
For GitLab, a merge request will be mergeable if it has no conflicts and if all required approvers have approved the pull request."
That does not seem to be the case however. I can atlantis apply a non-mergeable MR, and I confirmed that the atlantis pod is checking mergeable status:
I can try setting it to approved, but I would prefer to use mergeable, as our process requires two approval for a MR to be considered mergeable.
Thanks for looking into this!
Cheers,
Gabor
The text was updated successfully, but these errors were encountered: