Documentation
¶
Overview ¶
Command test-budget reports how much of its Bazel timeout budget each test target actually consumed, and fails when a target that RAN is close enough to its budget that the next growth will break it.
It exists because a timeout breach is the worst possible place to learn that a suite outgrew its budget: by then the merge queue is already blocked, and the run that discovers it has burned the full budget to tell you. Two properties of Bazel conspire to hide the growth until exactly that moment:
- The action cache. A target whose inputs did not change is not executed at all, so a lane can report green while executing a small fraction of the targets it gates. A master run that executes 2 of 25 targets says nothing about the 23 it skipped, and the first PR that touches a common dependency executes all 25 cold.
- Bazel warns only in the other direction: `--test_verbose_timeout_warnings` tells you a target's budget is too BIG. Nothing warns that it is nearly too small.
So this tool reads the run's Build Event Protocol stream, keeps the targets that genuinely executed (cache hits carry the duration of some earlier run on some earlier machine and would be noise at best), and compares each against the budget the BUILD file gave it.
Usage:
bazel query 'tests(//scope/...)' --output=xml --xml:default_values > targets.xml test-budget -bep .bazel-bep.jsonl -targets targets.xml [-threshold 0.6]
Source Files