4

My team <team-1> is sharing a github repo with <team-2>. The repo looks something like this (Simplified example):

infrastructure/
       |
       |-- .github/CODEOWNERS 
       |
       |-- directory1/ 
               |
               |-- subdirectory1.1/
               |
               |-- subdirectory1.2/
              |
       |-- directory2/ 
               |
               |-- subdirectory2.1/
               |
               |-- subdirectory2.2/
              |
       |-- directory3/ 
               |
               |-- subdirectory3.1/
               |
               |-- subdirectory3.2/
       

<team-2> is the CODEOWNER of every directory in the repo, and my team <team-1> owns only subdirectory1.1 and subdirectory2.1.

In otherwords the CODEOWNERS file looks something like this:

github/CODEOWNERS

* @mycompany/team2
/infrastructure/directory1/subdirectory1.1 @mycompany/team1
/infrastructure/directory1/subdirectory1.1 @mycompany/team1

Given the aforementioned, what I would like to do is exclude team2 from every folder that team1 owns, ideally without removing the wildcard in the codeowners file.

* @mycompany/team2
/infrastructure/directory1/subdirectory1.1 @mycompany/team1 AND EXCLUDE TEAM2
/infrastructure/directory1/subdirectory1.1 @mycompany/team1 AND EXCLUDE TEAM2

What is the best way to do that without rewriting the whole codeowners logic?

torek
  • 389,216
  • 48
  • 524
  • 664

1 Answers1

1

If by "code owner" you means push/write access to a folder, this is not supported natively by Git, or GitHub: if you can push to part of a repository, you can push to all of the repository.

What you might consider is pushing to an intermediate gateway repository, on a server you control, and where you can set-up an authorization layer, like gitolite

With Gitolite, you can with VREF restrict pushes by the names of dirs and files changed.

In your case:

repo foo
        RW+                             =   @team2
        R                               =   @team1

        RW   VREF/NAME/infrastructure/directory1/subdirectory1.1 @team1
        RW   VREF/NAME/infrastructure/directory1/subdirectory2.1 @team1

Once the push is validated by Gitolite, that same server could in turn push to GitHub.


But a more natural way would be to split the repository in two, referencing the team1 content in the main parent teeam2 repository, as a submodule.
Not easy though, considering it would involve history rewriting, and folder reorganization.

VonC
  • 1,129,465
  • 480
  • 4,036
  • 4,755
  • Yeah, I believe submodules would be the bet handling such situations, you could also have a look here in addition to the official documentation: https://www.atlassian.com/git/tutorials/git-submodules, and here https://github.blog/2016-02-01-working-with-submodules/ to get started with submodules. – Utmost Creator Nov 01 '21 at 11:22
  • @UtmostCreator Agreed. But it involves splitting the repository in two first, using git filter-repo: https://stackoverflow.com/a/58983975/6309 – VonC Nov 01 '21 at 11:24
  • I have splitted up 2 project with default git tools, but having read [git filter-repo](https://github.com/newren/git-filter-repo), seems powerful enough, not to mention the fact that it is recommended by the owners! it really may come in handy in such situations! – Utmost Creator Nov 01 '21 at 11:33