pipetree lint <directory> silently treats a directory as an unparseable file
#18
Notifications
Total Time Spent: 3 minutes
oleks
3 minutes
No due date set.
Dependencies
No dependencies set.
Reference: oleks/pipetree#18
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why:
pipetree lint .(or any directory argument) takes the directory-vs-file distinction as "file that failed to parse": it lands inunanalyzableand exits 4 with "could not analyze .". Observed directly.Exit 4 is arguably defensible (it is not clean), but the diagnostic is misleading — a user who meant
-C .(report mode over a scan root) gets a parse-error message about a directory rather than a usage hint. Low severity, cosmetic-to-moderate: the two invocations differ by a flag and the failure mode does not point at the mistake.Suggested fix: in
projectsFromFiles(lint_cmd.go), stat each argument; if it is a directory, either exit 2 with "pipetree lint: is a directory — did you mean -C ?", or treat it as a scan root. Prefer the explicit usage error.Acceptance:
pipetree lint <directory>no longer reports a misleading "could not analyze" parse error-C <path>Links: lint_cmd.go
projectsFromFiles, oleks/pipetreee9989b5Surfaced while implementing the Woodpecker CI linter in oleks/pipetree (specs/001-woodpecker-ci-linter). Priority: low — cosmetic diagnostic issue, not a functional defect.
Fixed in
114c0bc, both acceptance boxes done.checkFileArgsinlint_cmd.gonow stats every argument before anythingis parsed. A directory exits 2 with:
One deliberate non-change, worth recording because it looks like an
oversight: a missing file still lands in
unanalyzableand exits 4,not 2. In hook mode the argument list is the push's changed files, so a
path that disappeared between the diff and the lint is a fact about the
tree, not a malformed command line — turning it into a usage error would
misreport a real condition. Only the directory case was ever the
misleading one.
Tests:
TestDirectoryArgIsAUsageError(exit 2, names the problem, pointsat
-C, and asserts the old "could not analyze" wording is gone) andTestMissingFileStaysAParseErrorpinning the distinction above.⏱ worked | 13-08-26 | session oleks/3b3844a4 | +3min | session-total 3min (lane-release) | elapsed from timeline