search

andrewring / github-distributed-owners

A tool for auto generating GitHub compatible CODEOWNERS files from OWNERS files distributed through the file tree.
MIT License
17 stars 1 forks source link

"No such file or directory" upon `OWNERS` file deletion #48

Open lukasschwab opened 1 month ago

lukasschwab commented 1 month ago

Hello — encountering some strange behavior!

I have a private project with an empty OWNERS file at the project root and non-empty OWNERS files in various subdirectories. Usually this works fine.

If I delete the root OWNERS file, this tool fails with an opaque error message: Error: No such file or directory (os error 2)

$ github-distributed-owners --version
github-distributed-owners 0.1.9
$ github-distributed-owners --output-file .github/CODEOWNERS    # Succeeds
$ rm OWNERS
$ github-distributed-owners --output-file .github/CODEOWNERS
Error: No such file or directory (os error 2)
$ touch OWNERS
$ github-distributed-owners --output-file .github/CODEOWNERS    # Succeeds

Is there some OWNERS file cacheing going on under the hood, maybe?

Ty for any help!

lukasschwab commented 1 month ago

If I delete the root OWNERS file

Red herring: I encounter the same error if I delete a non-root OWNERS files as well.

Adding the --verbose flag doesn't change the output — just the one error message.

lukasschwab commented 1 month ago

Ah, the issue is pretty straightforward: if you delete an OWNERS file without staging the deletion, it remains in the git ls-files results returned by allow_git_files: https://github.com/andrewring/github-distributed-owners/blob/b700b84d8195b31865fb9293686c19059fa0e2d6/src/allow_filter.rs#L39-L60

Staging the file deletions with git add resolves the errors I observed:

$ rm OWNERS
$ github-distributed-owners --output-file .github/CODEOWNERS
Error: No such file or directory (os error 2)
$ git add OWNERS
$ github-distributed-owners --output-file .github/CODEOWNERS    # Succeeds

Consider adding a check for existence before parsing? Didn't find an obvious solution for excluding unstaged deletions from git ls-files results.

Edit: gave this a shot myself. The issue is actually upstream of file-parsing: conversion to canonical paths in AllowList::from.