Show which linters actually ran on a review (even when they had no findings) #11

New issue

Closed

opened 2026-05-01 14:00:51 -07:00 by auto-review · 0 comments

auto-review commented

2026-05-01 14:00:51 -07:00

Collaborator

Desired: the review body includes a small "Linters" section (collapsed details, or a one-liner) listing what ran, what was skipped, and why. Something like:

Linters: ruff (ok, 0 findings), shellcheck (ok, 2 findings), markdownlint (skipped: not on PATH), eslint (skipped: no JS/TS files in diff)

Two transparency wins:

Operator misconfiguration ("oh, hadolint isn't installed on the gateway") becomes visible from the PR review itself, not buried in gateway logs.
PR authors see what the bot did and didn't check, so they don't assume coverage they didn't get.

Implementation: each LinterRunner in crates/ar-tools/ already returns a name + result. The orchestrator currently filters to "produced findings"; just preserve the full set with status (ok | skipped: <reason>) and render it in the review body. Probably belongs alongside the pre-merge checks section.

Cap noise by collapsing into a markdown details block by default.

Right now the review body only mentions linters when they produce findings. If a Python file is in the diff and ruff isn't installed on the gateway host, the bot silently skips it — operators have no way to know the review was thinner than expected. **Desired:** the review body includes a small "Linters" section (collapsed details, or a one-liner) listing what ran, what was skipped, and why. Something like: ``` Linters: ruff (ok, 0 findings), shellcheck (ok, 2 findings), markdownlint (skipped: not on PATH), eslint (skipped: no JS/TS files in diff) ``` Two transparency wins: 1. Operator misconfiguration ("oh, hadolint isn't installed on the gateway") becomes visible from the PR review itself, not buried in gateway logs. 2. PR authors see what the bot did and didn't check, so they don't assume coverage they didn't get. Implementation: each `LinterRunner` in `crates/ar-tools/` already returns a name + result. The orchestrator currently filters to "produced findings"; just preserve the full set with status (`ok` | `skipped: <reason>`) and render it in the review body. Probably belongs alongside the pre-merge checks section. Cap noise by collapsing into a markdown details block by default.