[lmm]

I find CI very valuable even on my solo projects.

> what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here?

The key is hermetically/reproducibly - you don't want to run commands on some random machine, you want to run commands on a well-controlled/versioned machine that won't change under you, that you can recreate at will. Which sure you should be able to do with Nix or something, but the kind of person who doesn't want to use CI doesn't want to use Nix either.

And the other key is whose machine? Particularly when it comes to e.g. Macs, which are expensive. Maybe you have a spare server farm in your closet, but most people don't.

[gizzlon]

For a solo dev, what are the advantages of _not_ building on your own machine?

Is the compiling and test running too resource intensive?

Do you build every commit? If so, why?

I see the value in larger teams, but for solo stuff I just find it slow and annoying. I'm using go, and it compiles fast, so that could be a part of it.

[lmm]

> For a solo dev, what are the advantages of _not_ building on your own machine?

I end up with all kinds of random crap on my own machine. It's very easy to accidentally e.g. globally install a library that wasn't properly listed in my dependency management. So having a separate standardised/controlled build environment is a good way to catch those. It also helps with flaky tests or random "works on my machine" problems - this way my tests are at least getting run on two quite different machines (different OS/arch/etc.)

[skydhash]

> The key is hermetically/reproducibly

Why not use VMs? Libvirt is scriptable enough for that. And LXC/Incus can be used if you want the shorter starting time.

[lmm]

Ok, that solves like 20% of the problem. How (and where) are you provisioning these VMs? How are you managing what versions of what are installed on them, and is that process reproducible?

None of this is hard, exactly, but you do have to put in the legwork of doing it, and it's mostly only the big players who've done so.

[skydhash]

A lot of VM managers allows to clone from a disk. And some even allows for an overlay layer on top of a read-only disk.

Creating a build machine is not rocket science.

[lmm]

It's not rocket science. As I said, it's a case of doing the legwork. But you do have to actually do the work rather than just handwave it away. Ok, your VM manager allows you to clone from a disk and maybe allows you to have an overlay layer. Great. Now draw the rest of the owl.

[kelnos]

These days the reproducibility part is trivial with a Docker container, as much as it's a mess of a technology.

[lmm]

Docker containers are great until you need to upgrade something. Then what do you do, rebuild the container and hope that none of the things that change break anything in a surprising way?