Does CODEOWNERS support nested teams?

Hello,

I work in an organization with nested teams. I’m wondering if the use of nested teams in CODEOWNERS is supported, as I’m not seeing automatic reviewers for this very simple config:

# More about this file at:
# https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners.
# Each line is a file pattern followed by one or more owners.

# These owners will be the default owners for everything in
# the repo, unless a later match takes precedence. Order is
# important; the last matching pattern takes the most precedence.
* @org/team/dev

/build @org/team/infra

Is this supported? Do I have the syntax wrong? Thanks in advance for your help.

1 Like

:wave: Welcome!

Nested teams are definitely supported. If you had a whole bunch of teams assigned here, some of which were nested under the others with many of the same people, you might run into some weirdness, but this seems straightforward.

I think the path syntax might be off. It probably should be /build/ or build/ depending on the behaviour you want.

More here: About code owners - GitHub Docs

Thanks for the reply.

Okay, I see that the examples in the docs use a trailing slash for /build/, whereas I did not. The gitignore pattern format would suggest this is okay, though: “If there is a separator at the end of the pattern then the pattern will only match directories, otherwise the pattern can match both files and directories.”

The docs do say, “If any line in your CODEOWNERS file contains invalid syntax, the file will not be detected and will not be used to request reviews,” so that might explain why catch-all rule isn’t working either.

Will try adding the trailing slash and report back. Thanks.

Better late than never, right?

It was my experience that nested teams are not supported, at least not in my particular set of circumstances. Perhaps it was due to the fact that some of the groups were private.

Anyway, the teams are pretty small, and in my case I was more interested in representing expertise than responsibility, so it made more sense to assign by individual, as the next member of @org/team/dev isn’t necessarily going to be an expert on the legacy spaghetti represented by /here/be/dragons.