Yes, that should work. But switches to a push versus pull.
In theory it could be seen as a build assets that could also be pulled.
As in a GitHub actions CI asset? Yes that would work but wouldn’t technically be git. 
Yes, that was the idea.
Would it need to be?
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
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 
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
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
That could be possible but i’m not sure it would be easy to use
Thanks 
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.
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
an orphan branch is just a branch with its own history (starts off with no parents).
you can empty it out and store/track whatever in it.
guix uses it to store gpg pub keys.
to avoid local eval, it can just store a single json file of nixosConfiguration store-paths.
this also keeps track of the history of deployments.
CI:
- builds artifacts and uploads them to a cache
- pushes a json file
{ "hostname": "/nix/store/...blah..." }to the orphan branch
Agent:
- polls orphan branch and does something fancier than this gist:
#!/usr/bin/env bash
set -euo pipefail
TEMPDIR=$(mktemp -d)
trap 'rm -rf "$TEMPDIR"' EXIT
# get cached store-path from json file
git clone --depth=1 --branch="$ORPHAN" "$REPO" "$TEMPDIR"
STOREPATH=$(jq -er --arg h "$(hostname)" '.[$h]' "$TEMPDIR"/cache.json)
# TODO: add all the fancy reboot logic
CURRENT=$(readlink /run/current-system)
if [[ "$CURRENT" != "$STOREPATH" ]]; then
# download cached store-path
nix-store -r "$STOREPATH"
# update profile
nix-env -p /nix/var/nix/profiles/system --set "$STOREPATH"
# activate
"$STOREPATH"/bin/switch-to-configurtaion switch
fi
i can imagine something like this could fit in nicely with comin.
if not, hopefully the idea is not too off and helps a little.
1 Like
I responded in the issue you created [Feature Request] Home Manager support · Issue #11 · nlewo/comin · GitHub.
Hi lewo, could you put it more prominently in the readme, that currently only gitlab tokens are supported for authentication. That is kind of a show-stopper for me (and I assume other people), and it would be really nice to see that at a glace. Or rejoice immediately when that changes and I’m re-evaluating.
Btw. any specific reason you don’t support “deploy keys” (as ghithub calls them), i.e. repository specific ssh-keys with read-only access? Or are you and I’m just misunderstanding?
I actually never consider to avoid the evaluation on the target machine … I’m however not sure this could fit well into the current comin model
I think bento does that, so at least the community has a tool. I’m really a fan of keeping it simple and not overloading with features especially in the early stages. I really like the simplicity of comin.
Quick question, the instructions in the repo specifically mention adding it to configuration.nix - am I correct in my interpretation, that means it doesn’t support flakes?
No, it actually only supports flakes! I think the readme should be more explicit about that btw.
1 Like
In the readme, the only mention to the authentication is a link to the documentation and this documentation starts by “Currently, only the GitLab personnal access token is supported”. I would actually prefer to avoid talking about authentication directly in the readme itself to keep it short.
The only reason is that I didn’t take time to try with GitHub (all my NixOS configuration are on GitLab instances).
But, it seems the current implementation is almost working for GitHub: we should just add another option allowing the user to provide a user name (which is not required by the GitLab auth).
Note there is an issue on this topic: Support private GitHub repositories · Issue #6 · nlewo/comin · GitHub (i should fix it in the next following weeks).
Correct and Cachix Deploy also avoids the evaluation on the target.
I agree with you. Also, I have a lot of other features to add before considering this use case…
Thank you for you message and I ping you when the GitHub auth is implemented 
1 Like
Thank you for sharing your ideas!
I don’t plan to think/work on this topic soon but there is an issue related to this use case.
1 Like
Actually, GitHub personal access token (PAT) works like GitLab PAT… so, the autentication with GitHub was already working!
So, i then added a section in the comin documentation to authenticate on GitHub private repo.
1 Like
