For the past few months, I've been building a Nix-specific CI service, and quite a few people have been productively using it, so I thought I'd Show HN it.
You might be wondering why build a Nix-specific CI. It turns out its quite hard to get a really good CI setup for Nix without spending a lot of time or money on it (or both), and even then solutions don't tend to be optimal.
Garnix, on the other hand, handles everything, and simply. Just create an account, install the GitHub app on the repositories you want, and you're good to go! Each package gets its own GitHub check, and separate log output, which makes it really easy to figure out what went wrong (you can see an example here: https://garnix.io/build/X9knYZOB). Builds are very fast compared to e.g Github Actions. The build artifacts are made available in a Nix cache so you never have to rebuild locally. And there are builders for x86-64 Linux as well as M1 Macs and aarch64 Linux.
Try it out: https://garnix.io. It's free, though if you like it, consider donating! (Note that it only works with flakes.)
Cheers, Julian
But is it open-source? I can't find the code.
(In general the idea of a license that's viral like GPL, but oriented towards green and renewable energy, seems like an interesting thought to me.)
I am from one where we still burn coal for heat (along with plastic bottles, tires, and rubber). You can imagine the impact of the electricity produced here. Yet there are IT jobs here and we're using many of the same products you do.
I've been using Drone and GitLab CI for years and likely won't be using anything like what you're describing because green energy is simply not available, and probably won't be for the next 50 years at the very least.
Hosting CI on the other side of the planet is a no-go for various reasons (we self-host everything since it makes a lot of sense for us).
How is that? You run the entire infrastructure on solar panels or something?
I've been wanting to write a blog post about what this means and how much it matters in practice, but there's a lot of research to do still. If someone here works in the area, please get in touch!
David Roberts, a very wonky and wonderful climate journalist, had Google's director of energy on his podcast to talk about Google's goal of having all their data centers operate on 24/7 CFE. This podcast is why I'm surprised any hosting provider has managed to do achieve 24/7 CFE because its an order or magnitude more difficult than achieving "100% CFE".
Here is the link to that episode: https://www.volts.wtf/p/volts-podcast-michael-terrell-on#det...
If you're interested in this enough to choose your hosting provider based off their energy mix I think you'd really enjoy his substack and podcast.
For other comment readers if you the difference between 100% CFE and 24/7 isn't clear, Google's blog post announcing their goal of 24/7 CFE explains the difference between the two and why 24/7 CFE is waaaay more difficult and currently only something a company with Google's resources could do.
Smells a bit like greenwashing to me...
I've been working on simplified hosting for nixosConfigurations; likely I'll launch paid plans along with that, since otherwise costs will be too high for me to shoulder, and anyhow free hosting leads to abuse or the moral hazard of accidentally using too many resources. I still have some hope for a donation-based system for individuals, and paid plans for companies, though.
I do think about open-sourcing it as well. I've been thinking about a license that would require only running it (and derived software) on green energy; that way, if competition were to arise, cheaper/dirtier energy wouldn't be what we would be competing on. But figuring out whether that's plausible, and what the consequences of the decision would be, is hard!
It's great in practice, and I would love for all electricity use to be non-renewable, but it's saying that many people in many countries are not allowed to use the software due to something entirely out of their control.
Also, for whatever reason (in addition to the specific ones above), GitHub action runners are just slow...
In short: garnix is faster, has more features, and is easier to set up.
Maybe an analogy: nix is a package-lock.json. Docker is a package.json (with no version bounds) and a node_modules directory. You can just copy that node_modules directory around so everyone has the same setup, but it's much harder to introspect than a lock file, and the way you go about updating it is deleting the folder and rebuilding everything - no fine-grained control over one specific dependency.
Also, "gar nichts". But we would say gar nix for short.
There are of course situations in which you'd prefer that, though!
I just had a play with Garnix - and have to say I am impressed. Nicely executed.
Nice to see nix and flakes hitting hackernews through projects/services like this.
