In a perfect world, you can scale CI indefinitely. However, I don't think it's a simple as that. As mentioned in the post, even with a hermetic build system your CI times become entwined with your dependency graph, no matter if you're able to shard it over remote executors or not.
The block you've quoted specifically mentions gating _merges_. I still think its prudent to run ~all tests after merge, with automatic reverts if tests start failing. I really want to make sure that people think of CI, merges, and deploys as pieces of a larger puzzle and not a monolith.
I updated the language around this in [0], hope that makes it clearer as to my intention.
Thanks for the clarification! fwiw Uber's monorepo treats CI and merges as the same, and deployments separately [0].
What it comes down to is engineering a solution to "mitigate a broken main" (automatic reverts) or a solution to "keep main green" (gating commits on a green build/test).
Submit Queue such as described in e.g. Uber’s “Keeping master green at scale” absolutely does scale, as demonstrated by their paper. What I’m referring to is that naively serializing commits does not. I’ll improve phrasing.
The block you've quoted specifically mentions gating _merges_. I still think its prudent to run ~all tests after merge, with automatic reverts if tests start failing. I really want to make sure that people think of CI, merges, and deploys as pieces of a larger puzzle and not a monolith.
I updated the language around this in [0], hope that makes it clearer as to my intention.
[0]: https://github.com/felixmulder/felixmulder.github.io/commit/...