Sep 4, 2023Julian K. Arni

Updates (September 4th, 2023)

ARM builds, private inputs, badges, new team, funding

A lot has happened since our last blog update. The gist of it is:

Product Improvements
New team members
Funding
Hosting - call for beta testers
NixCon

Product improvements

We've been hard at work, both improving our existing product, and extending it in various ways. We'll talk about the latter in another blog post, but the improvements to Garnix CI are:

We've added support for native aarch64-linux builders. These are much more efficient than the emulation we had previously had. If you're developing for a Raspberry Pi or embedded devices, this can help a lot!

See the documentation on garnix.yaml for more information on how to enable ARM builds on your repository.

Private Inputs

It was previously impossible to use private inputs in Garnix. That was a big issue: private repositories worked only if they had no private dependencies.

Flakes have had support for private inputs for a while now, and it comes in two forms: via SSH keys, and via tokens. SSH keys are very convenient for developer machines; after all, that's the mechanism we already using for cloning, so that there's not much by way of setup. And (for GitHub, at least), you have access to a private input if and only if you have access to the repository corresponding to the input itself, which is exactly the behavior you want.

But the opposite is true for GitHub Apps. Apps are granted access to specific repositories via the GitHub UI, and this access is mediated by tokens. If Apps used SSH keys for private inputs, a separate key would have to be generated, and permissions managed separately from the tokens. This is both a lot of work, and error-prone.

We decided to go with the second option. We'll describe exactly how to do this in an upcoming blog post.

homeConfigurations support

Garnix now builds homeConfigurations, making it easy to manage your Home Manager configurations.

We had originally tied the signup process to both authorizing and installing a GitHub App. Authorization is what gives us the possibility to sign in with GitHub, and to verify a GitHub username is really yours. Installation, on the other hand, gives an App specific access to, for example, the code in your repository.

The problem with tying these together is that you might not want to install the app in any particular repo when signing up for Garnix, either because you haven't yet created the repo you want to use, or because you're collaborating on one that already has Garnix installed. This made the process quite confusing. With recent changes, things should be much smoother.

Badges

Garnix now also has support for dynamic badges, which succintly convey the build status of a repository (number of failing or succeeding builds). Here's a live example:

The badges entry in our documentation has an interactive helper that you can use to try out badges for your repository.

Note that because there's no easy way to authenticate a badge access, these badges won't work with private repositories.

Only run when either garnix.yaml or flake.nix is present

Previously, Garnix would run on every repository, and fail if no flake.nix was present. Now, it first checks whether either of these files is present before starting the build. This results in two improvements:

You can install Garnix for the whole organization on GitHub, and then not worry about fiddling with the GitHub UI again; instead, you can turn Garnix on and off in the source code of the repository itself.
If you are flake- and garnix-ifying a repository on a branch, you can turn Garnix on and it will only run in that branch, without spurious failures in other ones.

New team members

Until recently, I (Julian Arni) was working on Garnix alone. It was getting quite hard to both make progress on features, and maintain reliability with a growing user base. Luckily, two amazing people joined: Sönke Hahn and Greg Pfeil.

Sönke was the team lead at my first Haskell job. He taught me a lot of what I know about software and processes. We wrote servant together (with Alp Mestanogullari); he also wrote one of the first Haskell games, Nikki and the Robots. Since then he's worked as Senior Software Engineer at Twitter, and Director of Software at Originate, as well as freelancing for various projects. He's joining as CTO of Garnix.

Greg was one of the early Garnix users, which is how I met them. It'd take an entire series of blog posts to talk about the work they've done in the past; my favourites are an avalanche risk map, a rewrite of Conal Elliott's concat, a couple of languages, and recursion-scheme libraries in Haskell, Scala, Dhall, and Idris. They are joining as Founding Engineer.

Funding

We also got funding to develop our product. This in turn means we're going to stop accepting donations. To all of you who contributed - thanks so much for supporting garnix!

Hosting - call for beta testers

We've been working on a big feature that we aren't quite ready to release publicly: hosting of NixOS machines. You specify NixOS configurations in your flake.nix, and Garnix builds and deploys them, with zero downtime. If you or your company would like to try this out, get in touch. Beta-testers will get a chance to collaborate on defining the product, and will get a lot of support from us.