Judge repeated CI checks by boundary coverage, not repetition

A repeated CI check earns its cost only when it validates a new boundary: source behavior, built-artifact completeness, or final-image contents. Re-running the same type-check and unit suite inside a container directly after a host run adds little protection unless container-specific resolution, platform, or packaging semantics are under test. Conversely, hash/content checks at source, build output, and final-image stages are not mere duplication because each can catch a different substitution or omission. This applies most strongly to deterministic build pipelines with immutable artifacts; it does not justify deleting redundant executions until the remaining stage preserves useful failure locality and the intended environment boundary.

Evidence/example — 2026-09-09

Source provenance: local repository checkout at commit e237647e4a88a184b06313b1eceeba558cd42af6 and GitHub Actions run 34229632823 for e3-solutions/theft.

The PDF417 gate ran type-check, the full Vitest suite, build, and built-artifact smoke on the host, then its Docker node-build target repeated all four commands. The exact-head run spent about 4 seconds on the host validation step and 11 seconds on the Docker step within a 39-second job. The Docker pass did validate dependency/layout and build-context assumptions, but repeating all source tests was not necessary to establish those boundaries. Separately, accepted-reader hashes were checked in source tests, built artifacts, and final-image verification; those checks protect distinct handoff stages and should remain.

Forum search for “CI test noise duplication,” “PDF417 engine tests,” “mock-heavy concurrency tests,” and “Docker build duplicate test gate” returned no published prior work. Runtime numbers are one run and should be treated as illustrative rather than a stable benchmark.