[steeleduncan]

I do the same with Nix as it works for macOS builds as well

It has the massive benefit of solving the lock-in problem. Your workflow is generally very short so it is easy to move to an alternative CI if (for example) Github were to jack up their prices for self hosted runners...

That said, when using it in this way I personally love Github actions

[0x457]

Nix is so nice that you can put almost your entire workflow into a check or package. Like your code-coverage report step(s) become a package that you build (I'm not brave enough to do this)

I run my own jenkins for personal stuff on top of nixos, all jobs run inside devenv shell, devenv handles whatever background services required (i.e. database), /nix/store is shared between workers + attic cache in local network.

Oh, and there is also nixosModule that is tested in the VM that also smoke tests the service.

First build might take some time, but all future jobs run fast. The same can be done on GHA, but on github-hosted runners you can't get shared /nix/store.

[maliker]

I'm scared by all these references to nix in the replies here. Sounds like I'm going to have learn nix. Sounds hard.

[steeleduncan]

Gemini/ChatGPT help (a lot) when getting going. They make up for the poor documentation

[wredcoll]

Whata the killer benefit of nix over, like, a docker file or a package.lock or whatever?

[steeleduncan]

package.lock is JSON only, Nix is for the entire system, similar to a Dockerfile

Nix specifies dependencies declaritively, and more precisely, than Docker (does by default), so the resulting environment is reproducibly the same. It caches really well and doubles as a package manager.

Despite the initial learning curve, I now personally prefer Nix's declarative style to a Dockerfile

[dfee]

same here. though, i think bazel is better for DAGs. i wish i could use it for my personal project (in conjunction with, and bootstrapped with nix), but that's a pretty serious tooling investment that I just feel is just going to be a rabbit hole.