I have never had to run a build that takes more than a few minutes, so I'm unfamiliar with these sorts of long-running builds.
I definitely agree on investing to make builds faster, but when they're a few minutes and the build will go down to slightly fewer minutes, those 'marginal' gains don't seem worth the increased build cost.
Just throwing more compute at the problem isn't always the answer either. The build tools I've been using over the past few years (Webpack and now Vite) have gotten so much faster on their own, which shows that there's loads of slack in our code and lots of room for improvement there before we need to throw more compute at it.
Also, I'm certainly not just twiddling my thumbs while it's running...
Am I the odd one out? Feels like a bit of a straw man argument from MS/GH trying to justify a blanket switch to more powerful runners 'because the data says so'
Do the math _for your business_ and _your use-case_
If you're doing fullstack web dev and writing lots of end to end tests, you'll run build times into dozens of minutes without even trying (since those involve spawning web browsers…)
I definitely agree on investing to make builds faster, but when they're a few minutes and the build will go down to slightly fewer minutes, those 'marginal' gains don't seem worth the increased build cost.
Just throwing more compute at the problem isn't always the answer either. The build tools I've been using over the past few years (Webpack and now Vite) have gotten so much faster on their own, which shows that there's loads of slack in our code and lots of room for improvement there before we need to throw more compute at it.
Also, I'm certainly not just twiddling my thumbs while it's running...
Am I the odd one out? Feels like a bit of a straw man argument from MS/GH trying to justify a blanket switch to more powerful runners 'because the data says so'
Do the math _for your business_ and _your use-case_
reply