Is something I said on Bluesky last week. Here is a longer take on this:
I know Garnix quite well. We have the pleasure to count them as one of Numtide's customers. Julian and I launched the Nix Swiss-French meetup together. And I have been using them on my home repository for the past 6 months. So that's the disclaimer and context.
It's also why I know and understand Garnix quite well. Like I said in my post, it's surprising to me that not more people are using it today. To me, Garnix is the perfect Nix CI. Let me share what I see:
- No CI-specific YAML. Whatever is in your flake.nix that runs on your machine, also runs in CI.
- No vendor lock-in. If you don't like it anymore, it's easy to move back to GitHub Actions, or deploy your own buildbot-nix instance.
- A globally shared binary cache.garnix.io. So every new project feeds and shares their build results. Faster compile for everyone. And no need to configure a different cache for each project. And because only the Garnix CI can push to the cache, you only need to trust the Garnix build infrastructure.
- Supports the quad: Linux and macOS. Both with x86_64 and aarch64.
- 30s runs with hot `/nix/store`. Unlike GitHub Actions, builders don't flush their `/nix/store` on every run. That, and good hardware is what makes it possible to get ultra fast build turnarounds.
TL;DR: Point Garnix to your repo with a flake.nix in it, and you have a CI.
Then combine this with blueprint to keep your flake super lean. Mergify + renovate to get automated flake updates. And you have a really nice setup.
The best is when I pull my dotfiles repo and everything is already prebuilt. No amount of customization I do on top of nixpkgs and NixOS is going to penalize me. And Nix is really the language for people that like to fearlessly customize things.
Ok, enough rambling for a day. Does the vision make sense or are there aspects you’re considering that I haven’t touched upon?