Support Relationships in CODEOWNERS (or Approval Rules)
<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=385209) </details> <!--IssueSummary end--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> Currently we can use [CODEOWNERS](https://docs.gitlab.com/ee/user/project/code_owners.html) to control the approvers for individual parts of the codebase, or [approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html) to cover more generic requirements. These are both all-or-nothing options with no granularity beyond mandatory or optional. We would like to propose a mechanism is provided where relationships can be defined between elements of the code base, perhaps using an approach similar to [merge request approval segregation of duties](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#merge-request-approval-segregation-of-duties) For example if we have a `CODEOWNERS` thus: ```plaintext * @alice /path/to/file-1 @bob @carol /path/to/file-2 @dan /path/to/file-3 @dan /.gitlab/CODEOWNERS @erin ``` We would like to be able to specify a rule that - if `file-1` is changed then `@bob` or `@carol` have to approve (existing CODEOWNERS capability) - if `file-3` is changed then `@dan` has to approve (existing CODEOWNERS capability) but - if `file-2` is changed then `@dan` has to approve (existing CODEOWNERS capability) **and** one of `@bob` or `@carol` for *reasons*, e.g. because `file-1` is directly consuming `file-2` (proposed new approval rule capability) At the moment there is no easy way to systemise these sorts of relationships leading to an incomplete approval chain.
issue