Repository navigation
Support negation globs #116
Description
Negation globs seemingly don't work. For example, I can't do something like this:
- '!(workspaces)/**/sourcing/**/*'
to say that I want this team to own any folder that has a "sourcing" subfolder in the path, but not within any "workspaces" folders.
This works just fine when tested with compgen. code_ownership doesn't seem to throw an error when validating, but when checking a path that should be owned under that glob, say lib/sourcing/some_file.rb, it incorrect states that it's not owned. Interestingly, it still correctly updates the CODEOWNERS file with the negation glob.
So now, instead of having single glob that covers most of this team's ownership, I will have to explicitly map out each folder instead.
Activity
mscrivo commentedon Feb 7, 2025
It seems this may be more a limitation of
Dir.globrather than this gem. It doesn't seem to support glob negationsashleywillard commentedon Feb 7, 2025
Hi @mscrivo! Thanks for filing this issue. You're correct, currently
code_ownershipdoes not support this syntax, and there is that limitation withDir.glob. One way to add support for excluding globs would be to add anunowned_globsarray for teams. We would welcome this contribution if you'd like to make a pull request!mscrivo commentedon Feb 10, 2025
This is trickier than I thought. Making it so that it understands
unowned_globsis not that hard forvalidatefor example. But the tricky part is how to translate it toCODEOWNERSfile. At first I thought, ok we can just list the globs inunowned_globsin theCODEOWNERSwith no team specified, but what if another team's config does own them? How to reconcile all the possibilities into a validCODEOWNERSis not clear to me.EDIT: Actually, I think what we need to do is for any overlapping globs where one team owns it and another team has it in the unowned_globs, we need to make sure the glob for the team that owns it comes, comes last. For example, say you have:
and
Then the CODEOWNERS should look like this:
with this, team bar would own:
lib/team_thing/some_filebut team foo would ownshared/team_thing/some_filewhich is the desired outcome I believe?mscrivo commentedon Feb 11, 2025
Digging more into this, it seems that CODEOWNERS entries are already sorted by least specific to most specific paths, so we may be able to make the assumption that if you have an unowned_glob defined on a team, you're doing it because both of these are true:
If those assumptions hold, then we don't have to change any logic for the CODEOWNERS generation. Or even if they may not, we can add a validation error an unowned_glob that is less specific then it's owned counterpart?
@ashleywillard does that make sense to you?
btw I have a PR in progress here