[usrbinenv]

I don't understand the hype around CI and that it's supposedly impossible to run something like that without Git, let alone Github. Like sure, a nice interface is fine, but I can do with a simpler one. I don't need a million features, because 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? It can probably be built internally if needed and it certainly doesn't need to depend on git so much - git can trigger it via hooks, but that's it?

I think the real problem is we were sold all these complex processes that supposedly deliver better results, while in reality for most people and orgs it's just cargo culting, like with Kubernetes, for example. We can get rid of 90% of them and be just fine. You easily get away without any kind of CI in teams of less than 5-7 people I would argue - just have some sane rules and make everyone follow them (like run unit tests before submitting a PR).

[duped]

> just have some sane rules and make everyone follow them (like run unit tests before submitting a PR)

and thus you discover the value of CI

[account42]

You could also just get managers that are not worthless.

[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?

[ncruces]

GitHub CI lets me test my package, for free, in all these: https://github.com/ncruces/go-sqlite3/wiki/Support-matrix

Which is actually useful.

[IshKebab]

The big deal is that GitHub provides it for free. Plus it integrated properly into the PR workflow.

Good luck implementing merge queues yourself. As far as I know there are no maintained open source implementations of merge queues. It's definitely not as trivial as you claim.