pipetree lint <directory> silently treats a directory as an unparseable file #18

Closed
opened 2026-08-13 18:24:29 +03:00 by issuer-agent · 2 comments
Collaborator

Why: pipetree lint . (or any directory argument) takes the directory-vs-file distinction as "file that failed to parse": it lands in unanalyzable and 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
  • Prefer: exit 2 with a usage hint pointing at -C <path>

Links: lint_cmd.go projectsFromFiles, oleks/pipetree e9989b5

Surfaced while implementing the Woodpecker CI linter in oleks/pipetree (specs/001-woodpecker-ci-linter). Priority: low — cosmetic diagnostic issue, not a functional defect.

**Why**: `pipetree lint .` (or any directory argument) takes the directory-vs-file distinction as "file that failed to parse": it lands in `unanalyzable` and 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: <path> is a directory — did you mean -C <path>?", 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 - [ ] Prefer: exit 2 with a usage hint pointing at `-C <path>` **Links**: lint_cmd.go `projectsFromFiles`, oleks/pipetree e9989b5 Surfaced while implementing the Woodpecker CI linter in oleks/pipetree (specs/001-woodpecker-ci-linter). Priority: low — cosmetic diagnostic issue, not a functional defect.
issuer-agent added the priority/low label 2026-08-13 18:24:29 +03:00
oleks added the agent/wip label 2026-08-13 18:27:40 +03:00
oleks added this to the pipetree-board project 2026-08-13 18:27:43 +03:00
Owner

Fixed in 114c0bc, both acceptance boxes done.

checkFileArgs in lint_cmd.go now stats every argument before anything
is parsed. A directory exits 2 with:

pipetree lint: . is a directory, not a Woodpecker config file -- did you
mean `pipetree lint -C .` to lint everything under it?

One deliberate non-change, worth recording because it looks like an
oversight: a missing file still lands in unanalyzable and 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, points
at -C, and asserts the old "could not analyze" wording is gone) and
TestMissingFileStaysAParseError pinning the distinction above.

Fixed in `114c0bc`, both acceptance boxes done. `checkFileArgs` in `lint_cmd.go` now stats every argument before anything is parsed. A directory exits 2 with: ``` pipetree lint: . is a directory, not a Woodpecker config file -- did you mean `pipetree lint -C .` to lint everything under it? ``` One deliberate non-change, worth recording because it looks like an oversight: a **missing** file still lands in `unanalyzable` and 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, points at `-C`, and asserts the old "could not analyze" wording is *gone*) and `TestMissingFileStaysAParseError` pinning the distinction above.
oleks closed this issue 2026-08-13 18:29:41 +03:00
oleks added spent time 3 minutes 2026-08-13 18:29:48 +03:00
Owner

⏱ worked | 13-08-26 | session oleks/3b3844a4 | +3min | session-total 3min (lane-release) | elapsed from timeline

⏱ worked | 13-08-26 | session oleks/3b3844a4 | +3min | session-total 3min (lane-release) | elapsed from timeline
oleks added agent/worked:oleks/3b3844a4agent/worked:oleks/3b3844a4:3min and removed agent/wip labels 2026-08-13 18:29:50 +03:00
Sign in to join this conversation.