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.
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?
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
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.
I really like the model where the various nodes autonomously poll a few repositories. This way those central machines hosting the repositories do not need to have access to any of the nodes and make them a less appealing target for attackers.
I see no mention of it in the repo but would it be able to authenticate to a Forgejo instance? I think the auth mechanism is similar to GitLab. Iāll try it out.
Also it happened to me already to lose SSH access to the box because of a bad config and this model would helps in some of those cases.
Thanks for writing this tool, Iāll definitely try it out soon.
