Skip to content

Acceptable CODEOWNERS Groups Should Inherit from Parent Group

Problem

Currently, as per the CODEOWNERS documentation for the CODEOWNERS file to reference a group it is not under you must first add that group to the project.

The documentation describes a situation like this:

group-x
├── subgroup-y
│   └── project-b
└── project-a

In this scenario, for @group-x/subgroup-y to be a valid CODEOWNERS target, that group must be first invited to project-a.

However, given the following layout, where project-a is instead a project that exists under subgroup-z:

group-x
├── subgroup-y
│   └── project-b
└── subgroup-z
    └── project-a

If subgroup-y is invited to subgroup-z, that group membership isn't respected by project-a's Code Owner configuration. For subgroup-y to be eligible as a Code Owner it must additionally be invited to project-a.

Real usecase:

group-x
├── engineering-group
├── datascience-group
└── product-group
    ├── project-a
    └── security-group
        └── project-b

In this case, both engineering-group and datascience-group contain no projects, and are only used to hold members. Both groups are invited to product-group which contains common groups and projects, but they still have to be added additionally to projects within product-group and security-group for CODEOWNERS to recognize @group-x/engineering-group or @group-x/datascience-group as valid Code Owners.

Proposal

I would like to propose that groups invited to other groups are eligible as Code Owners in any project within the group or its subgroups. e.g. inviting engineering-group to product-group should allow CODEOWNERS in project-a and project-b to recognize @group-x/engineering-group as valid Code Owners

Concerns

Enabling shared groups as eligible code owners could mean existing Projects with Code Owners may suddenly have more eligible approvers. This is only the case if the project has specified a shared group in the CODEONWERS file at the time we enable this. Adding a shared group to the CODEOWNERS file appears to be signalling that they want Code Owners to work this way so potentially a non-issue.

Additional considerations

  1. Update the documentation to clarify that shared groups are now eligible as Code Owners
  2. Update the diagrams in https://docs.gitlab.com/ee/user/project/codeowners/#group-inheritance-and-eligibility to give a better real-world example as outlined in this Issue.
  3. Create a release note

⚠️ Blockers

We need to decide how we will protect existing CODEOWNERS files from this change. One suggestion is to create a mechanism to enable this while we deprecate the old behavior.

e.g. if the file starts with # enable-shared-groups then we would run the code to lookup shared groups. Then we would deprecate the current exclude-shared-groups behavior over the next major release by adding a deprecation notice to projects that do not have the comment enabling this behavior.

Until we decide how to handle this we will pause development on Draft: Include invited groups as CODEOWNER (!171919 - closed) and Draft: Update CODEOWNER documentation (!172062 - closed) and mark this issue as workflowblocked

Additional items

These docs need to be retested and updated once this is complete https://docs.gitlab.com/user/project/codeowners/troubleshooting/#incompatibility-with-global-saml-group-memberships-lock

Edited by 🤖 GitLab Bot 🤖