Configuring merge request "approvals_before_merge" via API is not respected in the UI
Summary
Updating a project's MR settings for approvals_before_merge
via API does not affect the approval checks for the project's Merge Requests. Configuring the settings through one interface does not affect the settings that another interface acknowledges.
Steps to reproduce
- Create a new project
- Add a group as the default approvers
- Via API, update the
approvals_before_merge
to 1.-
curl -X POST -d '{"approvals_before_merge":1}' -H 'Content-Type: application/json' -H "Private-Token: $TOKEN" https://$GITLAB_HOST/api/v4/projects/29/approvals
-
TOKEN
-- Access token with API privileges -
GITLAB_HOST
-- Hostname of the enterprise Gitlab instance
-
-
- Via UI, go to the project's merge request approvals settings (
Settings
->General
->Merge request approvals
). - The
No. approvals required
is still0
. - Opening a merge request shows that no approvals are needed to merge.
- Notes on other permutations:
- Adjusting other merge request settings (e.g.,
merge_requests_author_approval
) are reflected in both the UI & API.
- Adjusting other merge request settings (e.g.,
What is the current bug behavior?
The API reports a successful update to the settings, and a GET request for the settings confirms the change occurred. Unfortunately,
the UI reports that No. approvals required
is a different value. Future merge requests that are opened will only adhere to the setting
displayed in the UI.
What is the expected correct behavior?
- That the UI acknowledge the values updated via API.
- That merge requests opened afterwards to abide by the settings configured via API.
Relevant logs and/or screenshots
-
Screenshot of the UI, showing the merge request approvals settings
-
API payload from
/projects/29/approvals
-
A similar issue that was opened up recently -- https://gitlab.com/gitlab-org/gitlab-ee/issues/12008
- What this issue shares with
12008
is that there is a disconnect between what is configured via UI & what is configured via API. - A distinct difference is that
12008
configures through the UI and reads from the API. This issue specifically configures the settings via API, and none of the settings are respected in the UI.
- What this issue shares with
Output of checks
(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
Results of GitLab application/environment info
- GitLab Enterprise Edition 11.10.4-ee
- I'm not personally an admin of the instance; I'd have to request them to add any additional information
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
)
Possible fixes
None to propose.