This has been the bane of my entire career. I have never, not once, encountered a CI system that could run the test suite faster then my development machine.
Which is absurd. Cloud resources on servers with more CPUs then I have, and yet the difference in timing is measured in tens of minutes.
From what I've seen this is usually caused by CI pipelines being overly cautious, starting from a pristine state and trying to cover every possible edge case.
Spin up new node, congrats, now you have to clone the whole repo from scratch. Oh, "npm install" was not cached, let's download half of the internet again, pull ":latest" of some multi-GB docker images while you are at it. For good measure, "make clean", because...you never know and nobody bothered to architect our build system to use a more sane tool than Makefiles, btw remember to only use make -j3, because rumor has it that the build fails intermittently when using more cores! Finally, run every test that couldn't possibly be affected by the commit in question, preferably the big e2e-suite. As someone else mentioned above, all of this running on some dog-slow cloud network attached disk.
There you have it. Spinning up more compute is not the solution, it's the cause. Keep one machine on and improve on your build tooling. I guarantee it will be magnitudes faster than any ephemeral pipeline.
This is usually a result of following 'cloud best practices' instead of being pragmatic.
For example, using Kubernetes with Docker where each pod is some virtual ECS 4-core whatever instance, assuming scaling the workload over a 1000 instances will be fast. Which in your case will lead to said pods individually spending 90% of their time running 'npm install' , and each pod is way slower than your desktop PC.
Different tests have different needs and bottlenecks. For example, if you're running unit tests, with no external dependencies, you'd want to separate out the build process, and distribute the artifacts to multiple test machines that run tests in parallel.
The choice of using a few big machines or more small ones is usually up to you, and is a wash cost-wise. However I do need to point out AWS sells you 192 core machines, which I'd wager are WAY faster than what you're sitting in front of.
And Amdahl's law is a thing as well. If there's a 10 minute non-parallizable build process, doing a 10 minute test run on a 192 core machine vs doing an ~0 minute test run on infinite machines ends up being only a 2x speedup.
And there's such a thing as setup costs. Spinning up an AWS machine from an image, setting up network interfaces, configuring the instance from scratch has a cost associated with it as well. And managing a cluster of 1000 computers also has its set of unique challenges. And assuming that if you ask Amazon for a 1000 machines at a drop of the hat, and plan to use each for a minute or two, AWS will throttle the fuck out of you.
All I'm trying to say with this incoherent rambling is KISS - know your requirements, and build the simplest infra that can satisfy it. Having a few large stopped instances in a pool might be all the complexity you need, and while it flies in the face of cloud best practices, it's probably going to be the fastest to start up.
I would argue the problem is for all the CI systems out there at the moment, there all "stupid": i.e. none of them try to predictively spin up an environment for a dev who is committing on a branch, none of them have any notion of promoting different "grades" of CI worker (i.e. an incremental versus a pristine) and none have any support for doing something nice like "lightweight test on push".
All of this should be possible, but the innovation is just not there.
> notion of promoting different "grades" of CI worker (i.e. an incremental versus a pristine) and none have any support for doing something nice like "lightweight test on push".
Which ones don't support that? Anything with a Docker cache, for example, can build layers efficiently, reusing previously built layers. Build triggers let you choose when to start a job, so GH actions, for example, can trigger a full test on any PR and a light test on any commit to a branch.
> And assuming that if you ask Amazon for a 1000 machines at a drop of the hat, and plan to use each for a minute or two, AWS will throttle the fuck out of you.
I haven’t scaled that far out, but I thought that was the whole point of cloud platforms like AWS, GCP and Azure
But then what will you contribute to the hour long weekly meeting where 13 managers present the status of their poorly defined CI metrics and other "action items"?
Not my experience. The CI systems I dealt with most recently, for example, were very much compute-bound. Way too weak VMs for the runnres, and way too few of them. With CI builds taking each of upward 2h, and capacity to run maybe 10 of them in parallel, this pretty much destroys any ability to work with small commits - you have to squash them before submitting for review anyway, otherwise you destroy anyone else's ability to get their changeset through CI for the rest of the day.
This is entirely solvable by getting more resources. At least 2x more runners, each at least 2x as beefy. You could go 10x and I doubt it would be anywhere as expensive as the amount of money company wastes on devs waiting for CI. Alas, good luck convincing people managing the infra of this.
There was caching of third-party dependencies, but at least 2/3 of the time was spent on various tests, which for domain-specific reasons weren't trivial. Sure, everything there could be optimized further, but this is a textbook case of a problem which can be solved by adding more compute for a fraction of the cost of dev-hours spent trying to optimize compilation and test times.
> I guarantee it will be magnitudes faster than any ephemeral pipeline.
Only if you have a single job to run. In practice it doesn’t really matter to the dev whether CI takes one or 5 minutes. When it all goes over 5 minutes is when it gets annoying.
It depends on how much policy your organization has. If your organization requires AV scanners and other security crapware to be on all instances, how long does that take to install? And perhaps they require that you only use their AMIs, which then must be loaded up with extra software to be usable. And perhaps they require all auth use their special auth service, which takes 5m to sync with. And on and on. I've worked in places where it takes 20m to spin up a usable instance, so we ended up just keeping them on most of the time.
In an ideal world, the policy groups imposing these inefficiencies would get billed for the cost of their policies, but I've only ever seen situations where everyone else pays the cost of their incompetence.
Ah, yeah, we kinda have to work around the fact that the antivirus and scanner stuff keeps installing far after the time the instance is done processing the job.
On the plus side, I actually get actionable notifications from the stuff, so it’s not purely bad for me.
And yet the data is ephemeral, so in many cases could be done faster without the "real" block storage guarantees.
Github Actions is pay-per-minute-used, unfortunately, so they may have a negative incentive to speed things up. Unless people become frustrated enough to switch to a non-bundled provider.
Not all the data is ephemeral - stuff like node_modules needs to he cached and if you’re suggesting to use tmpfs then it’s like 50x more cost than fully tricked out cloud ssd which is already ridiculously expensive
You should just add an admission webhook that kubeadm’s your dev box onto the CI cluster with a taint that only your pods tolerate whenever you need to run the test suite. Call it edge cloud and people will love it.
There was a tech talk many years ago when one of the github engineers talked about how fast the github CI tests were (this was way before the microsoft aquisition). Literally seconds. I wonder if they're still that fast.
They absolutely are not. Hundreds of thousands of Ruby tests end up being pretty slow to execute. The CI machines have all dependencies pre-cached and different tests are parallelized across multiple VMs, yet still a full suite takes ~12 minutes.
> Cloud resources on servers with more CPUs then I have
The server the resources run on may have more CPUs than your dev machine, but are you allocating more CPU to the specific test job than you desktop has?
My experience is the opposite due to the insane overhead of the spyware^H^H^H antivirus and security services running on our personal devices. Some colleagues successfully applied for MacBooks since these are reasonably fast even while running the security services.
Which is absurd. Cloud resources on servers with more CPUs then I have, and yet the difference in timing is measured in tens of minutes.