Unassigned filepaths shouldn't fail

[AlexApriamashvili]

Hey team!

I've noticed that the current rules parser assumes that the owner will always be assigned to a corresponding file path. However, there are some situations when a specific owner is not required and ownership is not defined.

An example of such a file path could be an auto-updated or autogenerated code that is indexed for some reason. A more concrete example is all strings.xml files in an Android project that are auto-translated and added to a project by a bot on a periodic basis. This kind of change does not require any individuals or teams to verify the change, hence the CODEOWNERS pattern is redundant.

Setting no owner for file path in the CODEOWNERS file seems to be an undocumented feature in GitHub. First discovered in this article and then verified to be a working solution by using the built-in Github validator.

I believe that the current implementation of the parser expects owners to always be specified. I'm keen to understand if you would be open to making this rule parametrisable?

[hmarr]

Hey, I think this case should have been covered by #7. The "unexpected end of rule" case you linked to is checking that after parsing a line, if we're still looking for the pattern, we should have a non-empty string. That case should generally not be reached, unless an empty line is passed into the parseRule function.

I quickly tested out the behaviour you described and it does seem to be working:

$ ls
CODEOWNERS a.txt      b.txt      c.txt

$ cat CODEOWNERS
# All .txt files are owned by @mona
*.txt @mona
# But b.* files are unowned
b.*

$ codeowners -f ./CODEOWNERS
CODEOWNERS                                                              (unowned)
c.txt                                                                   @mona
b.txt                                                                   (unowned)
a.txt                                                                   @mona

Please let me know if I've misunderstood though!