Just read through Gregory Szorc’s notes on Facebook’s Dev Infrastructure at Scale talk and wanted to share:
In particular the section on how they do CI seems worth reading. One neat thing they do to speed up the process is to use code coverage to determine which tests to run.
Thought it would be worth discussing a bit to see if we could do something similar with velocity:core and what would be involved.
EDIT: Just saw that the HN thread for the main link discusses this too. This sounds like a nice, simple approach:
We have a home grown solution for this. We use pants (https://pantsbuild.github.io/) for our Python builds and phabricator for code reviews. Pants gives us a dependency graph so from which files get touched in a given diff, we can feed that back into pants to get the targets to build and the test suites to run. It’s not as granular as running individual tests in a suite for small changes, but it definitely helps cut most runs down to just a small percentage of all the tests. The ability to pants to build test suites in isolation is also pretty key since it means we can run a whole bunch of suites in parallel so in many cases the total test run time can be just the time of the longest individual suite.
As others have mentioned, kicking off full runs on a regular basis is important to make sure there aren’t weird cases that break and aren’t caught in this approach." - andrewjshults