3 ms·
The slowness in my tests comes not from having too few runners (we just dynamically spin up a runner for each commit, and it normally takes only a few seconds f
by deathanatos 4y ago
The slowness in my tests comes not from having too few runners (we just dynamically spin up a runner for each commit, and it normally takes only a few seconds for that), but from serialization in the CI pipeline. You cannot run tests until the code has been built; no extra runner can change that.
I need dev time to make the builds understand their inputs, and then cache more aggressively than we are, or something. (But I lack the dev time.)
- chrsig 4y agopipeline time is something that I spend a non trivial amount of effort on. caching and promoting images is an absolute must. caching images has it's downsides, too though. it can be a longer time period between when something in the dockerfile breaks and when it's noticed. generally speaking, my pipeline is generally 10-40% build time, 50-60% integration & system test time, 10% deployment time The system tests that're run deploy the entire dependency graph of services that my project depends on, which can take a bit to settle, has a high chance of transient failures relative to other parts of the pipeline, and notably has a fixed test run time. That last bit really raises the lower bound for how long the pipeline as a whole takes -- number of runners doesn't matter. The pipeline generally takes between 25-45 minutes, and runs on each push and is triggered by changes to dependencies to ensure backwards compatibility. I wouldn't do anything to make it take longer than it does now, and it can be frustrating. but the pipeline will catch things that would otherwise slip through the cracks.