Why is the code owners approval optional on the MR

I am seeing the code owners approval optional on the MRs but I don’t understand why.

Here’s .gitlab/CODEOWNERS.
Notice how I do not use the caret ^ character.

# Documentation at https://docs.gitlab.com/14.0/ee/user/project/code_owners.html
# Files can be specified using the same kind of patterns you would use in the .gitignore file. It uses globbing
# patterns to match against file names.

/integration-messages/**/*.yaml @von

Here’s what I get on the MRs:
As the code owners pattern matches I get the respective section but approval is optional.

Here are the repo approval settings for reference:

Hi @marcelstoer
don’t forget to add Approval rule for Code Owners

Thanks for the feedback. I just read that chapter (again) but I (still) don’t understand. Does any user listed in the code owners file - directly or through group membership - have to be explicitly listed as an eligible approver in the project settings? To me, that would somewhat defeat the purpose of the code owners file.

Either way, I tried adding the single user listed in my example file as an eligible approver but code owners approval is still reported as optional.

What we’re aiming for is requiring approval by one of the users listed in the rule plus approval as per the code owners file.

Do not add a user to the “Approvers”, but put there " Any eligible user" as described in that chapter.
And set a number of approvals to 1 or higher.

EDIT:
if I remember correctly any change in MR approval rules are applied to new MRs only. Already existing MRs are not updated. But it’s been some time since I checked it so I might be wrong.

Tried that as well, makes no difference.

Your memory serves you right; it’s like you describe (unless you can change the approval rules directly in the MR itself).

Alright, so is that user/group @von directly in members of the project? Not inherited from parent groups.

I will also link couple issues I found.

Hhmm, good point. I need to look into this.

While testing with different users I just found something (else) that isn’t in accordance with the documentation.

Code Owners | GitLab (14.0) says

The CODEOWNERS file is valid for the branch where it lives. For example, if you change the code owners in a feature branch, the changes aren’t valid in the main branch until the feature branch is merged.

So, I changed @von in .gitlab/CODEOWNERS to some other user in the feature branch I’m working on. Yet, upon creating a new MR GitLab is still listing @von as defined in the master branch. As this specific section disappeared in the 14.1 documentation I won’t file a bug :slightly_frowning_face:

master branch has @von in CODEOWNERS.
featurebranch has @otheruser in CODEOWNERS

I expect to see @von for MR featurebranchmaster since he is still only valid codeowner for master branch. Your change in MR wasn’t merged, yet. Otherwise anyone could change codeowners in feature branch and override codeowners in target branch.

Exactly, that’s what I thought when I read that paragraph. Maybe that’s the reason they removed and/or change the implementation in >14.0.

My testing with other users didn’t change the behavior. Thanks to some of the existing issues (you linked some, thanks) I realized there’s actually an API to pull detailed MR approval information from https://host/api/v4/projects/project_id/merge_requests/mr_id/approvals. It looks like this

{
  "id": 58033,
  "iid": 971,
  "project_id": 924,
  "title": "Testing code owners for MRs",
  "description": "",
  "state": "opened",
  "created_at": "2021-08-03T17:26:40.142+02:00",
  "updated_at": "2021-08-04T08:34:58.730+02:00",
  "merge_status": "can_be_merged",
  "approved": false,
  "approvals_required": 1,
  "approvals_left": 1,
  "require_password_to_approve": false,
  "approved_by": [],
  "suggested_approvers": [
    {
      "id": 189,
      "name": "***redacted-name***",
      "username": "hef",
      "state": "active",
      "avatar_url": "https://***redacted-host***/uploads/-/system/user/avatar/189/avatar.png",
      "web_url": "https://***redacted-host***/hef"
    }
  ],
  "approvers": [],
  "approver_groups": [],
  "user_has_approved": false,
  "user_can_approve": false,
  "approval_rules_left": [
    {
      "id": 44656,
      "name": "All Members",
      "rule_type": "any_approver"
    }
  ],
  "has_approval_rules": true,
  "merge_request_approvers_available": true,
  "multiple_approval_rules_available": false
}

What I read into it:

  • "approvals_required": 1 seems to match the “Any eligible user, 0 of 1” displayed on the GUI i.e. the MR approval rule unrelated to code owners
  • "suggested_approvers": [] is the one user I named in the code owners file for the affected artifact/path
  • "user_can_approve": false bothers me a bit as it could indicate that GitLab thinks that the code owners user isn’t eligible to approve. This in turn could explain why the code owners approval is marked as optional in the GUI. Maybe? Just guessing.

I went on and also pulled the /projects/project_id/merge_requests/mr_id/approval_state resource from the API.

{
  "approval_rules_overwritten": true,
  "rules": [
    {
      "id": 44656,
      "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
    },
    {
      "id": 44657,
      "name": "/integration-messages/**/*.yaml",
      "rule_type": "code_owner",
      "eligible_approvers": [
        {
          "id": 189,
          "name": "***redacted-name***",
          "username": "hef",
          "state": "active",
          "avatar_url": "https://***redacted-host***/uploads/-/system/user/avatar/189/avatar.png",
          "web_url": "https://***redacted-host***/hef"
        }
      ],
      "approvals_required": 0,
      "users": [
        {
          "id": 189,
          "name": "***redacted-name***",
          "username": "hef",
          "state": "active",
          "avatar_url": "https://***redacted-host***/uploads/-/system/user/avatar/189/avatar.png",
          "web_url": "https://***redacted-host***/hef"
        }
      ],
      "groups": [],
      "contains_hidden_groups": false,
      "section": "codeowners",
      "source_rule": null,
      "overridden": false,
      "code_owner": true,
      "approved_by": [],
      "approved": true
    }
  ]
}

This seems to dismiss my speculation from above. The second rule (44657 i.e. the code owner rule) says:

  • "eligible_approvers" → the one user listed in the code owners file → he actually is eligible to approve → no permission issues
  • "approvals_required": 0 → WHY?