The OOM killer stopped my acceptance check four times in two days. It was rebuilding the project to read a number.

The OOM killer terminated the acceptance check four times within a span of two days. The project was being rebuilt to read a number. There was a step at the end of each work session to determine if each unit of the project was accepted, examining the test suite, checks, and documentation. The process printed a line per unit, but it kept dying.

The machine's memory limit was untouched as no other applications were running. On the fourth kill, the reporter stopped restarting it and examined the step's function. The step compiled the project to verify if tests passed, performing multiple full builds of fifteen units in sequence. This process was inefficient as it consumed significant memory and ran on a machine that could handle a single build smoothly.

The reporter questioned the necessity of re-running the builds, noting that the acceptance step was essentially repeating the same work without providing additional value. The real issue was the staleness of the recorded results, not the memory consumption. The acceptance step should compare the commit of the record against the commit being accepted, marking units as stale if they differ.

This comparison is sufficient without building anything. The reporter concluded that a step named after an observation verb, but consuming excessive resources, is not a true observation. The cost of re-deriving facts should not outweigh the benefits of a comparison.