jjmschofield / github-codeowners Goto Github PK

based on https://github.com/jjmschofield/github-codeowners/pull/43/files from @FauxFaux

I'm told I have a validation error:

$ github-codeowners validate
Found rules which did not match any files [
  '/test.en.yml @org/team',
]

But in reality the file exists:

$ ls test.en.yml
test.en.yml

Had a browse around the codebase and didn't spot the bug, sorry.

$ github-codeowners validate
Found rules which did not match any files [
  '/some_file.yml @team'
]
$ echo $?
0

I would have expected this to return an error.

Further I tried to work around this by using wc -l but no dice:

$ github-codeowners validate | wc -l
Found rules which did not match any files [
  '/some_file.yml @team'
]
       0

Steps to reproduce

• In a git repo, add a submodule
• run github-codeowners audit -s -g
• See the error message:

failed to read lines from file github-codeowners [Error: EISDIR: illegal operation on a directory, read]

Output from terminal

Expected behavior

Ownership stats should be shown as expected without any error.
Submodules should be excluded, or included via a new parameter.

It is possible to "fool" this library into thinking a file is covered by codeowners, whilst GitHub will not apply code ownership.

Steps to reproduce

• Create a file in some nested subdirectory, e.g. /foo/bar/baz.txt
• Add a rule involving a wildcard to CODEOWNERS e.g. /foo/* or /foo/b*
• Run github-codeowners audit

Expected

• The file is considered unloved

Actual

• The file is considered loved

Notes

I've tested this scenario by raising a PR (in a private repo), and GitHub did not assign any code owners.

I'm using this as a CI step to require explicit owners for a monolith owned by multiple teams. Currently the CI step will fail if someone deletes a file that didn't have an explicit owner. This is obviously not desirable.

It would be nice to have an option like:

github-codeowners git --exclude-deleted-files develop HEAD

This way the CI can enforce that all new or modified files have owners.

It currently seems a bit random. I think alphabetically by team name is a good start. Other ideas are by number of files owned.

Despite wide usage, maintainer of underlying lib is seems to no longer be maintaining jergason/recursive-readdir#60

Replace lib.

Offer up a dependable interface so that other apps / scripts can consume the core functionality

Hey @jjmschofield, thanks much for this awesome library! 💯 Are you currently accepting contributions? And if so, would you possibly have time to review, merge, and publish? If not, I understand - I'm happy to fork.

I'd love for github-codeowners audit --unloved to support the use case of explicitly marking some files as unowned. My use case is basically to enforce 100% CODEOWNERS coverage by ensuring this command has no output, but then allowing some known exceptions to be explicitly listed in the CODEOWNERS file.

GitHub appears to support this: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#:~:text=owners%20are%20left%20empty

# In this example, @octocat owns any file in the /apps
# directory in the root of your repository except for the /apps/github
# subdirectory, as its owners are left empty.
/apps/ @octocat
/apps/github

Historically I'd been using @ghost entries, but GitHub's recent feature to present a UI for validation of files shows errors because that is not a real team.

As per:

"Invalid syntax includes inline comments and user or team names that do not exist on GitHub."

https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

Add a regex check when reading in code owners to ensure that owner names are valid for github.

Github has two potential formats for an owner which are valid:

• [email protected]
• @js-owner

https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

prevents loading files into memory if not required, perf improvement suggestion from @FauxFaux

Currently only the root .gitignore is respected

To help people support the schema at https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners

Where in:

"Invalid syntax includes inline comments and user or team names that do not exist on GitHub."

In a config (somehwere, somehow) create a list of allowed owners and make the validate command respect it.

{
  ...
  "validate":{
    ...
    "owners": {
      "allowed": [
        "@bob"
      ]
    }
  }
}

If multiple lines define ownership for a file then the owners are augmented.

The expected result would be that the later definitions overwrites earlier ones as stated here: codeowners-syntax

This is especially wrong for * ownerships.