Keep modules, lint cache and system packages in check builds (closes #130)
check / check (push) Canceled after 0s

On sneak's ruling in #130, check
builds keep three more things besides Go's build cache. In each stage of
the canonical Go Dockerfile, the system-package install and the module
download come before ARG CACHEBUST, so Docker keeps those layers until
the base image, the install line, go.mod or go.sum changes. Modules are
kept as a layer, not a cache mount, because Go does not check a cache
mount's files again. golangci-lint run also mounts golangci-lint's cache.
Every step that lints, tests or compiles still comes after ARG CACHEBUST,
both go test runs keep -count=1, and a step that also installs node
packages stays below the line. The policy, checklists, Go style guide,
README and script comments say the same.

Model: opus-5-5
This commit was merged in pull request #131.
This commit is contained in:
2026-10-18 16:56:25 +02:00
parent e3f79c49da
commit 065357920a
10 changed files with 168 additions and 83 deletions
+10 -3
View File
@@ -144,9 +144,16 @@ alpine. We provide:
`make hooks` installs the pre-commit hook that runs `script/precommit`.
Every stage of the `Dockerfile` declares `ARG CACHEBUST` as its first line after
`FROM`. The `script/` builds pass a new `CACHEBUST` value on every build, which
reruns every `RUN` step and keeps Go's build cache; `--no-cache` would empty it.
In every stage of a `Dockerfile`, `ARG CACHEBUST` comes right after the steps
that install system packages and download Go's modules, or right after `FROM` in
a stage with neither, and every step that lints, tests or compiles comes after
it. The `script/` builds pass a new `CACHEBUST` value on every build, which
reruns every `RUN` step after that line and leaves the layers above it and the
cache mounts in place; `--no-cache` would build those layers again and empty the
mounts. This repo's own `Dockerfile` declares `ARG CACHEBUST` right after `FROM`
in every stage: each stage installs system packages and node packages together
in one `script/bootstrap` step, and check builds may keep system packages but
not node packages.
## Rationale