apply fails with apply_requirements mergeable on gitlab < 15.6

[zerog2k]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

Overview of the Issue

error received when attempting to do atlantis apply on a gitlab MR with approvals, and
repo has Merge Checks "Pipelines must succeed" enabled, and
atlantis is configured with apply_requirements of mergeable

atlantis error:
Failure running apply operation: Pull request must be mergeable before running apply.

I am suspecting it's due to recent changes in atlantis to use the detailed merge request status instead of merge request status field of merge requests endpoint
71738f1#diff-22d1bafb2e6e476aabe2f33484daa3f74932c6e0266f0830d7d948b8b9f60183R224

however, the underlying gitlab api endpoint supporting the new field detailed_merge_status is newly added in gitlab 15.6:
https://docs.gitlab.com/ee/api/merge_requests.html#merge-status

Version history
The merge_status field was deprecated in GitLab 15.6.
The detailed_merge_status field was introduced in GitLab 15.6.

So currently, on gitlab versions older than 15.6 (e.g. 14.x), newest (?) versions of atlantis apply will not work with apply_requirements mergeable and repo merge checks of "pipelines must succeed" enabled.

Environment details

relevant repo section of atlantis.yaml file:

  - id: /.*/
    # apply_requirements sets the Apply Requirements for all repos that match.
    apply_requirements: [approved, mergeable]
    allow_custom_workflows: true
    allowed_overrides: [apply_requirements, workflow]

atlantis helm chart 4.12.1
atlantis version v0.23.3
gitlab ee 14.10.5

Suggestion

as atlantis does appear to be aware of the gitlab version, perhaps retain previous/older behavior w.r.t. merge_status vs detailed_merge_status fields, for gitlab < 15.6

{"level":"info","ts":"2023-03-22T20:29:36.607Z","caller":"vcs/gitlab_client.go:110","msg":"determined GitLab is running version 14.10.5","json":{}}

[zerog2k]

also confirmed workaround is to roll back to v0.22.2 which works with mergeable in apply_requirements

[nitrocode]

Yes, Atlantis only supports gitlab version 15.6 and higher due to the detailed merge status flag due to using the latest go gitlab package.

[zerog2k]

Hi @nitrocode
Looks like MergeRequest.MergeStatus is only deprecated, not removed, and still should be present in current go-gitlab package.
ref: https://github.com/xanzy/go-gitlab/blob/v0.81.0/merge_requests.go#L111-L113

Furthermore, as gitlab still supports 14.x & 13.x, I'm guessing there are a number of teams like ours where they may not be able to immediately upgrade to latest 15.x for reasons. In our case another team manages gitlab instance, and coordinating & planning can take some time.
ref: https://about.gitlab.com/support/statement-of-support/#version-support

Regarding possible solutions, another thought would be that MergeRequest.DetailedMergeStatus field would probably be empty (?) on gitlab <15.6 (as it's not present in the api), so perhaps that's another signal to fallback to MergeStatus field?
(I've never tried to code in golang, but it seems reasonably simple, so I may give it a try - not sure how we test/mock the various different provider [github, gitlab, etc] responses)

Anyhow, we have a workaround for the short-term (v0.22.2), until our team maintaining gitlab are able to upgrade to 15.6+.
(So hopefully having this documented will help anyone else running across this issue.)

[nitrocode]

See #2960 for more details on why the check was modified and the error thrown before modification

Please feel free to propose a pr. The maintainers would be happy to review