CodeOwners are not listed in the eligible approvers when in a cousin group
Summary
A ultimate customer is encountering a buggy behavior after implementing CODEOWNERS. The behavior is as described in #14060 (comment 363255886).
Steps to reproduce
- Create a parent group
- Create 2 subgroups; A & B.
- In subgroup A, make sure you add all the users that would be acting as codeowners.
- Under subgroup B, create a project in which you create:
- A CODEWONERS file under
.gitlab
folder, and assignsubgroup A
as codeowners. - A merge request.
- A CODEWONERS file under
- Review the MR eligible approvers
Example Project
What is the current bug behaviour?
- To have codeowners as eligible approvers for a MR in a certain project, you need to invite
subgroup B
intosubgroup A
or invitesubgroup A
into the project. - Codeowners widget hides eligible approvers.
What is the expected correct behaviour?
- Codeowners appear as eligible approvers without inviting any groups into the the project.
- Codeowners widget appear under eligible approvers.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
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`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true
)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
)(we will only investigate if the tests are passing)
Possible fixes
Edited by Sean Carroll