-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't correctly follow rules for ownership in nested directories #2
Comments
I suspect GitHub is actually using |
Thanks for pointing this out – you're totally right. And sorry for missing this issue until now! It's actually using pathspec, so I've updated the pattern matching logic to follow almost exactly what that library does. I tried it out with the example you provided and it seems to fix that behaviour. I also pulled the tests cases out into JSON file and ran them through the internal codeowners library to verify the new logic matches the canonical one, at least for the cases covered in that file. I'm planning on running a large project that uses code owners through both this library and the canonical GitHub one and comparing the results, which should help catch any edge cases I've missed. Once I've done that I'll tag a new release. |
I confirmed the new matching implementation is consistent with the canonical GitHub one over a large project, so I just released it in v0.3.0. Thanks again for reporting this! |
I've just noticed that this project parses the codeowners file incorrectly according to Github's specification (examples), given the following lines:
Then the file at
src/foo/bar.js
should actually be owned byuser-a
, this is because of this logic:(from https://docs.github.com/en/free-pro-team@latest/github/creating-cloning-and-archiving-repositories/about-code-owners )
Essentially the
/*
only matches direct descendants, not all descendants of a directory. This logic is the same for Gitlab too.The text was updated successfully, but these errors were encountered: