GitLab Next

Description

• API for approvers.

• For both project level and merge request level.

• Getting values and setting values.

• At the project level

  • The number of required approvals.
  • Explicit eligible individual approvers and eligible explicit group approvers.
  • Implicit eligible project member approvers.

• At the merge request level

  • The number of required approvals.
  • Explicit eligible individual approvers and eligible explicit group approvers.
  • Implicit eligible project member approvers.
  • Who has already approved.

• Validations

  • Should be same as Web UI.
  • When attempting to override at merge request level, should respect flag that allows for overridability. (This flag itself is part of scope. See below.)
  • Should respect mr required number needs to be >= project required number.
  • Should respect who are eligible to be added per existing logic.
  • Appropriate error messages if failed validations.

• Individual approvers

  • The individual approvers are explicitly set/returned in the Web UI. This should be the same in the API.

• Group approvers

  • A group approver is represented by the group in the system and reflected in the Web UI. So that should be the same in the API. E.g. Group A is a group approver with members X, Y, Z. Via the API, you should not return X, Y, Z as individual approvers. The API should only return Group A as an approver.

• Project member approvers

  • Under certain conditions (see description in https://gitlab.com/gitlab-org/gitlab-ee/issues/4134), project members with developer role or higher is eligible to approve. This should not be exposed via the API, because the API user can infer this on their own.

• Also allow the API to return and set the flag (in a project) to override approvals per merge request, i.e. the checkbox in the project settings:

Out of scope

Approving a merge request is out of scope and handled in https://gitlab.com/gitlab-org/gitlab-ee/issues/201