Two of the more expensive things we found in August were not bugs. They were configuration that had never had any effect, sitting in files that looked correct.
The images that could not be built
We enabled the Docker jobs in forge-git's CI. The point of the change was to start checking that the images actually build. The check failed immediately, on two different errors:
`` apps/web Module not found: Can't resolve '@forge-git/gitea-queue' packages/deploy-runner TS2307: Cannot find module '@forge-git/db' ``
Neither Dockerfile copies the whole tree. They copy workspace packages by name, and both packages were declared as dependencies but never copied into the image. The image had been unresolvable since the day it was written.
Why did nobody notice? Because the jobs had never run. They exited 127 for want of a Docker CLI, and before that they were skipped behind an earlier failing job. So the configuration was present, the intent was documented, and the outcome was nothing at all — for as long as the file had existed.
The volume that was never created
The second one is my favourite kind of wrong, because it was a performance fix that made no difference and then quietly stopped nothing.
Our e2e jobs were re-downloading roughly 113 MB of Chromium on every run. So we declared a named volume to cache it:
`` container.options: -v playwright-browsers:/root/.cache/ms-playwright ``
Then someone measured it properly. On the CI host, the runner was respawned with the new configuration, a job ran, and docker inspect on that job's container showed no such mount. The volume had never been created. Not on that run — at all.
container.options is inert on act_runner 0.6.1 for volumes, exactly as it is for --memory. The runner accepts the key, stores the configuration, and does nothing with it. We reverted the setting rather than leave it in place looking like a fix.
The pattern
Both failures come from the same gap: we verified that configuration was written, and never that it took effect. A setting in a file reads as a decision. It is actually a hypothesis.
The cheap test we now try to apply is asking what the observable difference would be if the setting were removed — because if there is no observable difference, either the setting does nothing or nothing depends on it, and both are worth knowing. The volume needed a docker inspect. The Docker jobs needed to be turned on, which is exactly what the change was for — three lines of CI that had been merged and never exercised.
The same class of failure is why we now treat "the job ran" and "the job did the thing" as separate claims. A pipeline that is skipped, superseded, or exited 127 is not a passing pipeline; it is an absent one, and absent looks a great deal like green.