Prove the Docker lint gate actually lints: defeat layer cache + negative control #108

New Issue

clawbot · 2026-09-04T00:02:10+02:00

clawbot commented

2026-09-04 00:02:10 +02:00

Sub-issue 2 of 2, split out of issue #104. Blocked on issue #107 — do not start this until that PR has merged.

Moving lint into a Docker build step introduces two ways to ship a false green. Both must be closed, and closing them is verification work with two timed container runs, which is why it is its own issue.

The two failure modes

A cached build lints nothing. A lint build on an unchanged tree returns success in well under a second having run no linter at all. Caching is explicitly waived for lint, so the lint layers must be forced to execute every time.
golangci-lint config verify fetches its JSON schema over an unpinned live HTTPS call. Decide deliberately whether to include it, and write the reasoning down. An unpinned network fetch inside the gate is the kind of thing REPO_POLICIES exists to prevent; if it is kept, justify it explicitly in the PR body.

Definition of done

Two consecutive script/lint runs on an unchanged tree both demonstrably execute the linter — paste the timings/output that prove it, not an assertion that it works.
Negative control: introduce a deliberate lint violation, confirm the gate fails with that specific finding, revert, confirm clean. Show all three outputs.
The config verify question above is decided and the decision is recorded in the PR body.
make check green.

Constraints

Evidence, not claims. A PR that says 'verified' without the run output does not close this.
Base branch is next, not main.

Sub-issue 2 of 2, split out of [issue #104](https://git.eeqj.de/sneak/pixa/issues/104). **Blocked on [issue #107](https://git.eeqj.de/sneak/pixa/issues/107)** — do not start this until that PR has merged. Moving lint into a Docker build step introduces two ways to ship a false green. Both must be closed, and closing them is verification work with two timed container runs, which is why it is its own issue. ## The two failure modes 1. **A cached build lints nothing.** A lint build on an unchanged tree returns success in well under a second having run no linter at all. Caching is explicitly waived for lint, so the lint layers must be forced to execute every time. 2. **`golangci-lint config verify` fetches its JSON schema over an unpinned live HTTPS call.** Decide deliberately whether to include it, and write the reasoning down. An unpinned network fetch inside the gate is the kind of thing REPO_POLICIES exists to prevent; if it is kept, justify it explicitly in the PR body. ## Definition of done 1. Two consecutive `script/lint` runs on an unchanged tree **both demonstrably execute the linter** — paste the timings/output that prove it, not an assertion that it works. 2. Negative control: introduce a deliberate lint violation, confirm the gate fails with that specific finding, revert, confirm clean. Show all three outputs. 3. The `config verify` question above is decided and the decision is recorded in the PR body. 4. `make check` green. ## Constraints - Evidence, not claims. A PR that says 'verified' without the run output does not close this. - Base branch is `next`, not `main`.

clawbot added this to the 1.0.0 milestone 2026-09-04 00:02:10 +02:00

clawbot referenced this issue

2026-09-04 00:02:31 +02:00

Run all linting in Docker via Dockerfile.lint + script/lint #104

clawbot commented

2026-09-05 11:32:53 +02:00

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted.

Model: fable-5-1

Closed at sneak's instruction, 2026-09-05: this was opened by an agent running on another machine outside the managed fleet, under superseded rules. Reopen if the content is wanted. Model: fable-5-1

clawbot closed this issue

2026-09-05 11:32:53 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/pixa#108