> I don't know which hypothetical CI runner you have in mind. Back in reality, most CICD services bill you on time spent running tests, not "core". Even core co

> I don't know which hypothetical CI runner you have in mind. Back in reality, most CICD services bill you on time spent running tests, not "core". Even core count is reflected as runtime multpliers. If you’re charging a runtime multiplier per core then there’s a cost per core. Included minutes on most runners are limited to basic versions with limited cores. Try xdist pytest on a default GitHub runner and get any speed up… > Moreover, services like GitHub not only offer a baseline of minutes per month, and on top of that provide support for self-hosted runners that cost you nothing. Except the cost of the hardware, sysadmin time for setting up and supporting ephemeral runners, monitoring, etc… > No, that's simply false and fundamentally wrong. You can run any test on any scenario independently of any other test from another scenario. In end to end system tests if you have 100 hitting at the same time how do you guarantee the underlying state is the same so the tests are idempotent? Also another example, I set up testing pipelines for an OS that ran in an FPGA in a HIL CI test. I had three of these due to operating costs. How could I parallelise tests that required flashing firmware AND have the most pipelines running as possible?