Comin: Git Push NixOS Machines

Announcements
1

The first version (v0.1.0) of comin, a deployment tool working in the pull mode, is out. Running on a machine, comin periodically polls Git repositories and deploys the NixOS configuration associated to the machine.

Features

  • Git push to deploy NixOS configurations
  • Support testing branches to try changes
  • Poll multiple Git remotes to avoid SPOF
  • Support machines migrations
  • Fast iterations with local remotes

I have also lot of other features in mind, which i will announce in this thread. Stay tuned!

24 Likes
2

I’m glad to see GitOps tools in the NixOS ecosystem!

2 Likes
3

How does it differ from NixOS built-in system.autoUpgrade?

1 Like
4

Before using comin, i have been actually using the auto-upgrade module for years! Basically, comin “just” provides more features (and a lot more are planned).

For instance, it pulls from several remotes and several branches as explained in this blog post: NixOS deployment: from push to pull ·

1 Like
5

Very cool!

Do you have any thoughts of how you would add a remote nix store that already has the system derivation built? The idea would be to avoid having to use CPU cycles on the target machine, that way comin could pull from the nix store cache a derivation that has already been built.

2 Likes
6

Nice. I was just looking into something like that.

Support for Github tokens would be good though.
But I assume that’s on the list :slight_smile:

What also would be nice:
Support for an external push trigger (that would just temporarily reduce the pull time to a few seconds)

And just as @sebohe said: Avoiding a full build on the server.
I assume cachix could help with that.
But maybe there is an option that doesn’t rely on 3rd party?

7

This should be pretty trivial, and I created an issue to track this point.

Actually, few months ago, i implemented a webhook allowing a CI to trigger a repository fetch. However, i didn’t use it because it was not convenient on laptops (which are not exposed on Internet) and the “local remote” feature made the job. So, i removed it from the codebase, mainly because it was not well tested.
I however still think this would be useful for some usecases and I opened this issue.

Sorry, i didn’t understand this question.

It is currently not possible, but comin is designed to support such usecases. The evaluation steps and builds steps are separated. We could then imagine an option to let comin waiting for the system storepath availability in a binary cache

I don’t know how this could be achieved with a remote store, but this is something that could be definitively addressed with a binary cache. See my above answer.

1 Like
8

I think it would be great for a CI an environment.
So you could have slow pulls and emulate a push by triggering a pull - to reduce the lag.

That was referring to cachix. I thought that cachix could help.

The idea was for the CI machine to do the build and create the cache artifacts.
And a switch on the server could then just re-use them.

But the question is whether there is another way without something like cachix.

9

You need somewhere to store and retrieve the nix store path. If you have a store path, which has been uploaded to a binary cache, then you can realize and activate straight from the cache. This avoids evaluation and building, and is how cachix deploy works. I don’t think this works with git alone though, so you’d need another service.

10

IIUC you could also copy the closure from the builder to the target - directly.
Not saying that’s a good option - but IIUC that could also be an option?

11

Yes, that should work. But switches to a push versus pull.

12

In theory it could be seen as a build assets that could also be pulled.

13

As in a GitHub actions CI asset? Yes that would work but wouldn’t technically be git. :slight_smile:

14

Yes, that was the idea.

Would it need to be?

15

It does limit the available forges, and even if support is added for multiple it would require each to duplicate the building. Considering this feature, I assumed the goal here was to stick to plain git…

  • Poll multiple Git remotes to avoid SPOF
16

Yes, initially, my goal was to stick to Git.
(I was however considering substituting from a binary cache instead of building locally.)

I actually never consider to avoid the evaluation on the target machine, since i don’t have this need. But i understand it could be pretty useful on some devices…
I’m however not sure this could fit well into the current comin model :thinking:

17

could a git orhpan branch be used to store/retrieve cached store paths and avoid local eval/build?
https://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt---orphanltnew-branchgt

18

This sounds super cool!

I would be interested in a feature that rolls the configuration back if access to the git server is lost on rebuild.

1 Like
19

That could be possible but i’m not sure it would be easy to use :thinking:

Thanks :heart:

I’m currently working on providing an history of configurations previously deployed. This should also provide a way to rollback from the previous deployed configuration.
In the future, we could then imagine something to trigger a rollback based on some events, as you suggested.

20

Would you consider work on extending this to support Home Manager and Nix Darwin as well? Or even desire it?

I have a couples of systems not running NixOS and I would like a unified way to configure a pull system that would guarantee to have the same “state” (in term of config) in all my systems.

I would be more than happy to help colaborate on this providing some PRs if you think it’s a good idea.

1 Like