the other side of this is that once you have the faster instances, the pressure will be off to do anything to improve build efficiency, and everyone will add more to the build till it's 20 minutes again.
Getting build times down is a difficult project because it's a cross functional task.
Like everything where you're involving a bunch of teams with no free space on their roadmaps, you have to be able to demonstrate that your team has done everything it can, and now the pressure needs to fall on the other teams. Like have a wiki or presentation to show how you have already trimmed the tests as much as possible, and the codebase is as small as possible, and you're not making 100 unnecessary docker layers, etc.
Thats your ammunition in the fight to get something like resizing the build instances on the other team's roadmaps and out of their budget.
I currently wait twenty minutes for CI to package a Go program that can be built on a laptop in ten seconds, because the “CI pipeline”—and every time I have to say that I choke on the words a little —involves twenty dependent steps, each of which installs Ubuntu. And this is a large, valuable company with thousands of engineers. I think having a development environment where the speed of the linker is even remotely relevant is a problem faced by a few special companies.
Sounds like it already is containerized, and that's the problem? A lot of places have CI setups that don't cache things anymore for various reasons. A while back there was a new YC startup announced whose product was essentially a SaaS for building Docker containers where they cache things for you.
Another cause of this problem is when CI workers are spun up and down on demand in the cloud, so VMs are constantly being set up from scratch.
The same reasons you can't just inline everything in a program, but break things into functions, modules, etc. Complex CI systems are, in my experiences, built up from components that are reused across multiple project builds and need to be encapsulated in a way that they can be plugged into any of those. Each component is containerized and caches as much as possible at each step, but that is still a lot of overhead.
> the pressure will be off to do anything to improve build efficiency, and everyone will add more to the build till it's 20 minutes again.
To rephrase this in a way that was not your intention, "developper laziness would only increase if the company paid for the beefier CI".
And I think that's often the crux of the discussion, at the base of it there's a perceived neglect and lack of effort, and it's only if all possible efforts have obviously been done that money should be attributed.
Thαt's where it feels less like a cut and dry ROI calculation, and there's a moral judgement aspect that is baked in but not often properly surfaced.
Getting build times down is a difficult project because it's a cross functional task.
Like everything where you're involving a bunch of teams with no free space on their roadmaps, you have to be able to demonstrate that your team has done everything it can, and now the pressure needs to fall on the other teams. Like have a wiki or presentation to show how you have already trimmed the tests as much as possible, and the codebase is as small as possible, and you're not making 100 unnecessary docker layers, etc.
Thats your ammunition in the fight to get something like resizing the build instances on the other team's roadmaps and out of their budget.