Skip to content

The shape of a successful build

 1 min Comparing file lists and sizes between successful builds can catch packaging regressions that exit codes never will.
Published

Jan 28, 2011

Exit code zero validates the process, not the product. A build can compile cleanly, package cleanly, and exit cleanly while shipping an artifact missing half its files—configure quietly disabled a feature when a dependency went missing, a subpackage split lost a directory, a packaging glob stopped matching. Every tool in the pipeline reports success because every tool did succeed at what it was asked to do.

The cheap detector: keep the previous successful build’s artifact inventory—the file list and the sizes—and compare the new one against it. A package that lost its /usr/share half shrinks. A build that stopped producing an optional plugin loses a file. A feature compiled out of an executable with the same name may show only a size delta, or evade a coarse threshold entirely. Flag the changes for the person releasing the build.

I proposed the check in the automated-builder discussion on arch-general, alongside a build-farm design. It remained a proposal.

Legitimate changes move the shape too: a new version adds files, or a compression change moves every size at once. The comparison should flag unexpected changes for inspection. It cannot decide from size alone whether the new artifact is correct.