<!--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=199203) </details> <!--IssueSummary end--> ## Problem to solve For large monorepos, putting everything in one CODEOWNERS files is hard to manage. Even with multiple sections https://gitlab.com/gitlab-org/gitlab/issues/12137 it can be hard to deal with. When CODEOWNERS files are being used for compliance to make sure specific approvals happen for specific files, having all CODEOWNERS in the same file means that any time anyone updates the CODEOWNERS file, the teams that have compliance requirements have to review the change. It should be possible for different teams to modify their CODEOWNERS independently of each other. ## MVP Proposal Support multiple CODEOWNERS files, like `app/frontend.codeowners`, so that they can be managed and protected individually. Multiple files would be compiled into a single file before they are parsed. * have an `include:` section * included filename starts with a dot `.` * have a suffix of `.codeowners` * can exist anywhere in the repo * single level of includes only (cannot include an included file) ### Example `./CODEOWNERS` ``` include some_folder/.common.codeowners . . . ``` `./some_folder/.common.codeowners` ``` some codeowners rules ``` ## Links / references The approach used for GitLab CI files and which has [been proposed](https://gitlab.com/gitlab-org/gitlab/-/issues/199203#note_1202128019) in this issue: ### Availability and Testing Add feature specs for nested CODEOWNER file scenarios. Optional E2E test to be added if feature specs cannot cover scenarios adequately. Exploratory testing of feature. Regression testing, please ensure associated MR is labelled with ~"pipeline:run-all-e2e" and `e2e:package-and-test` job is passing (in particular the `Create` stage tests).