What broke

A build on the station runs on a labelled runner. The runner's label — which name it answers to — used to point at a machine that already carried every tool the build needs. The build came to depend on one of those tools, a package manager, being installed at a known directory on that machine. The build's only accommodation was to add that directory to the search path, on the assumption the tool was already sitting in it.

Then the machine behind the label changed. The label came to point at a container image, and the container does not carry that tool. The build had not been changed: it still added the directory to the search path and asserted the tool was present. The first build after the change failed.

How it showed

A tool check that reported a missing tool. The build's own setup step listed the tools it requires and printed "missing" next to the package manager, then stopped with an error. The whole run lasted about two seconds from start to failure, on the first push after the runner changed.

The evidence is one line — the check loop used "command -v" on each required tool, and the package manager was the only one absent. The directory that had been added to the search path exists nowhere in the container.

What was watching

Smoke tests — the build's own "tools present" step — is what fired. It is a smoke test in the literal sense: before any real work, it asked whether the environment had what the job needs, and the answer was no. It caught the defect on the first run, in seconds.

Nothing was silent in the sense of sitting blind for long. The one step that should have been stronger — the step that adds the directory to the search path — is not a check at all. It blindly appends a directory and always succeeds, so it can neither confirm nor contradict the assumption that the tool is installed there.

Where it sits

This is a change failure: the environment behind the label changed, and the build's assumption did not change with it. It is also a structural failure: the build's own step for this tool checks for it but never installs it, so the build is correct only on a machine where the tool already exists.

The check did its job. The defect is not that the missing tool went unnoticed — it was noticed immediately. The defect is that the build said "this tool is required" and then left it to chance whether the machine had it.

What we did

The build's tool step no longer assumes the tool is on the machine. It checks for the tool, and when the tool is absent it installs it into the build's own space — the package manager is now fetched and made available rather than looked up at a directory that may not exist. Whoever writes this step into other repos will carry the same fix, since the pattern is copied between the station's builds.

What now fails loudly

• A build that needs a tool brings it with it. The step installs the tool when

it is absent, so a fresh container or a newly-provisioned machine runs green instead of red.

• A missing tool no longer depends on chance on the machine that runs the job.

The build is correct on any machine behind the label, not only on the one that happened to have the tool installed.