Dockerfile.lint has no .git, so gitignore-honouring linters walk a different file set than they do locally #56

New Issue

clawbot · 2026-09-03T20:29:12+02:00

clawbot commented

2026-09-03 20:29:12 +02:00

Salvaged from PR #43, which is being closed. This gap was measured but never tracked on its own.

Problem

Dockerfile.lint lints whatever COPY . . copies. A COPY . . build context has no .git (it is dockerignored, deliberately — see sneak/rfscan#35).

Linters that honour .gitignore — ruff, eslint, prettier — do so by locating the repository. Without .git they cannot, so the lint set inside the image is not the lint set on the developer's machine.

Evidence

sneak/rfscan's reviewer isolated it with .git as the only variable, same image, same tree:

`.git` in context	result
absent	`F401 ... build/x.py:1:8`, exit 1
restored	clean, exit 0

build/, dist/, .tox/, .nox/, htmlcov/ and *.egg-info/ are gitignored in that repo but not dockerignored. Any developer with build artifacts on disk gets a red script/lint for files git is ignoring. CI is unaffected — it clones clean. That is what makes it nasty: it fails only locally, only for some people, and looks like a real finding.

Note this is the opposite direction from #27 and #29

Those are about extra files reaching the image. This is about the image losing the mechanism that would have excluded them. Adding .claude to .dockerignore does not fix it, because the general case is every gitignored path.

Decision needed — two candidate rules

Canonical .dockerignore must cover the language's build-artifact and cache directories, not only agent scratch. Cheap, no build change — but it is a second list that must be kept in step with .gitignore by hand, which is the same hand-maintained-drift problem the canonical docs object to elsewhere.
Dockerfile.lint gets .git (dockerignore-negated for that build only), so the linter honours .gitignore the way it does everywhere else. Single source of truth by construction, at the cost of .git churn touching the lint layer's cache key — which matters little here, since CHECK_EPOCH already forces that layer to run.

The original reporter leaned to 2. It partially re-opens the .git-in-context question that sneak/rfscan#35 closed for the main image, so it wants a deliberate answer rather than an agent picking.

Blocked

This is downstream of the containerised-lint model landing on main — currently on next via PR #34. Do not open a PR for this until #34 merges.

Salvaged from [PR #43](https://git.eeqj.de/sneak/prompts/pulls/43), which is being closed. This gap was measured but never tracked on its own. ## Problem `Dockerfile.lint` lints whatever `COPY . .` copies. A `COPY . .` build context has **no `.git`** (it is dockerignored, deliberately — see [sneak/rfscan#35](https://git.eeqj.de/sneak/rfscan/issues/35)). Linters that honour `.gitignore` — ruff, eslint, prettier — do so by locating the repository. Without `.git` they cannot, so **the lint set inside the image is not the lint set on the developer's machine**. ## Evidence `sneak/rfscan`'s reviewer isolated it with `.git` as the only variable, same image, same tree: | `.git` in context | result | | --- | --- | | absent | `F401 ... build/x.py:1:8`, exit 1 | | restored | clean, exit 0 | `build/`, `dist/`, `.tox/`, `.nox/`, `htmlcov/` and `*.egg-info/` are gitignored in that repo but not dockerignored. Any developer with build artifacts on disk gets a red `script/lint` for files git is ignoring. **CI is unaffected — it clones clean.** That is what makes it nasty: it fails only locally, only for some people, and looks like a real finding. ## Note this is the opposite direction from [#27](https://git.eeqj.de/sneak/prompts/issues/27) and [#29](https://git.eeqj.de/sneak/prompts/issues/29) Those are about extra files *reaching* the image. This is about the image losing the *mechanism* that would have excluded them. Adding `.claude` to `.dockerignore` does not fix it, because the general case is every gitignored path. ## Decision needed — two candidate rules 1. **Canonical `.dockerignore` must cover the language's build-artifact and cache directories**, not only agent scratch. Cheap, no build change — but it is a second list that must be kept in step with `.gitignore` by hand, which is the same hand-maintained-drift problem the canonical docs object to elsewhere. 2. **`Dockerfile.lint` gets `.git`** (dockerignore-negated for that build only), so the linter honours `.gitignore` the way it does everywhere else. Single source of truth by construction, at the cost of `.git` churn touching the lint layer's cache key — which matters little here, since `CHECK_EPOCH` already forces that layer to run. The original reporter leaned to 2. It partially re-opens the `.git`-in-context question that [sneak/rfscan#35](https://git.eeqj.de/sneak/rfscan/issues/35) closed for the *main* image, so it wants a deliberate answer rather than an agent picking. ## Blocked This is downstream of the containerised-lint model landing on `main` — currently on `next` via [PR #34](https://git.eeqj.de/sneak/prompts/pulls/34). Do not open a PR for this until #34 merges.

~~clawbot referenced this issue 2026-09-03 20:29:36 +02:00~~

Close three gaps between the containerised-lint rule and its first adopters #43

~~clawbot referenced this issue 2026-09-03 20:30:12 +02:00~~

Milestone next: check-cache busting, build-context hygiene, lint in a container #34

clawbot commented

2026-09-06 16:27:51 +02:00

Closed: filed by the agent system outside the managed fleet that was shut down on 2026-09-06.

Model: fable-5-1

Closed: filed by the agent system outside the managed fleet that was shut down on 2026-09-06. Model: fable-5-1

clawbot closed this issue

2026-09-06 16:27:51 +02:00

Sign in to join this conversation.