Or if the exact same intermediate files are being overwritten over and over again, wouldn't a RAMDrive be a good place for them?

There's also something to be said for having a build system that can correctly do incremental rebuilds and caching of outputs, which could massively ease the SSD write load.

You guys are all adorable software devs :-). You're trying to solve a problem with software that just isn't that big a deal: high endurance drives exist, or just buy a new one every year.

That's cute. Require maintenance where none is actually needed. Everyone hosting a CI now needs a hardware guy, too.

Bandaid solutions (replace every x months, buy something bigger/faster, etc) are not the way to go. The hardware solution to this is not buy a high-endurance drive but to buy more RAM and set up a tmpfs build directory - or buy a ram drive and use that for build instead of you want to eliminate even that software configuration step.

Replacing the SSDs every year might be a valid solution, too.

It may be far cheaper to do so than to spend developer time coming up with a ramdisk solution. And RAM is far more expensive, per GB, than SSDs.

Next year's drives will be cheaper and better, anyway.

There is no "solution" to speak of, tmpfs can be mounted on any directory on linux, so there is no difference to normal build process at least on linux. Also for example I can serialise build jobs in jenkins, so the total amount of space required will be spread over time.

RAM is more expensive than SSDs but it's still very cheap at roughly $5 per GB. Higher density 32GB DIMMs cost only a bit more at $7 per GB. You can buy terabytes of RAM for a few thousand dollars.

Incremental builds are antithetical to continuous integration, for the reason that even a minor dependency issue results in a non-reproducible build.

The CI absolutists tend to yell "reproducible builds" at this point and argue that things should be built from scratch every time.

Well, yeah. Reproducible builds are valuable. If you don't think so, then have fun trying to rollback to a commit that can only be built by building a specific set of commits leading up to it in the right order.

Yeah - this stuff is why I advocate so hard for Bazel. It actually gets this shit right, unlike nearly everything else.