What is CI? CI, Builds, Agents

Somebody is wrong on the internet. Today it’s my turn? CI, ideally, is a deterministic function from your source tree to a boolean: are the tests passing or not? In practice, it usually also returns some artifacts: logs, build outputs, structured per-test output. (The de-facto standard for "what tests ran" is a JUnit XML file.) Thrice in my career, I've attacked (or been attacked by) build or CI problems. When CI gets slow enough (or non-deterministic enough), you suddenly find a lot of time on your hands to fix CI. I’ve observed a few patterns. Goals # Faster is better. More reliable is better. It must be possible to run CI against a commit that's not in main. (If you can only test after pushing, you destroy the important feedback loop that prevents one person’s problem becoming everyone’s.) The CI itself should be iterated on using itself. For example, going from two tests running serially to two tests running in parallel should be expressible as a commit in your code base. There is…