Automated deployments #2

New issue

Open

opened 2026-02-09 14:29:31 +01:00 by tdpeuter · 0 comments

tdpeuter commented

2026-02-09 14:29:31 +01:00

Owner

Using GitHub/Forgejo Actions, I have the following approach(es) in mind:

Push based system

Features/changes to the config are implemented in their separate branches. On every push, the modified derivations are built, as to check if they are valid. Once merged into the main branch, or when pushed to a test-<hostname> branch, the changes are pushed to the host and the services are restarted. The changes would be built on a build-host, with additional resources (mainly memory).

Caveats would be:

Any (illegal) change to the code would get deployed automatically.
The system should have a ssh user that is allowed to push changes to the new host.

Pull based system

Features/changes to the config are implemented in their separate branches, though 'hotfixes' should be possible as well. On every push, the modified derivations can be built, as to check if they are valid, but in this case I think it is less appropriate. Once merged into the main branch, or when pushed to a test-<hostname> branch, either a) the host periodically checks for changes (using system.autoUpgrade ?) and pull them in, or b) some kind of webhook system is implemented to let the host(s) know to pull the new changes. The changes would either be built on the systems themselves, as to spread the resource consumption, or be built once again on a centralized build-host.

Caveats I can think of:

If the derivations are built on a build-host, can these builds be pulled simply to each host?

Discussion

In both systems, the main branch should be protected with appropriate rules. I think putting signed commits and checking for those signatures in place is appropriate as well.

In both cases, rollbacks are a challenge to implement (myself). deploy-rs implements a magic rollback.

Documentation

Continuous integration with GitHub Actions
Setting up distributed builds

Deployment tools: colmena, deploy-rs, comin

Forgejo Actions Reference

NixOS deployment: from push to pull
Remote deployment NixOS & Flakes Book
CI/CD rebuilds via github

I would like to implement automated (semi-automatic) deployments of the NixOS machines. This would decrease the effort for deploying changes to (all) the affected hosts, including keys management. Putting a system in place and clearly defining the trust boundaries would be beneficial in my opinion. Using GitHub/Forgejo Actions, I have the following approach(es) in mind: ## Push based system Features/changes to the config are implemented in their separate branches. On every push, the modified derivations are built, as to check if they are valid. Once merged into the main branch, or when pushed to a `test-<hostname>` branch, the changes are pushed to the host and the services are restarted. The changes would be built on a build-host, with additional resources (mainly memory). Caveats would be: - Any (illegal) change to the code would get deployed automatically. - The system should have a ssh user that is allowed to push changes to the new host. ## Pull based system Features/changes to the config are implemented in their separate branches, though 'hotfixes' should be possible as well. On every push, the modified derivations *can* be built, as to check if they are valid, but in this case I think it is less appropriate. Once merged into the main branch, or when pushed to a `test-<hostname>` branch, either a) the host periodically checks for changes (using [`system.autoUpgrade`](https://search.nixos.org/options?channel=25.11&show=system.autoUpgrade.enable&query=system.autoUpgrade) ?) and pull them in, or b) some kind of webhook system is implemented to let the host(s) know to pull the new changes. The changes would either be built on the systems themselves, as to spread the resource consumption, or be built once again on a centralized build-host. Caveats I can think of: - If the derivations are built on a build-host, can these builds be pulled simply to each host? ## Discussion In both systems, the main branch should be protected with appropriate rules. I think putting signed commits and checking for those signatures in place is appropriate as well. In both cases, rollbacks are a challenge to implement (myself). [`deploy-rs`](https://github.com/serokell/deploy-rs) implements a magic rollback. ## Documentation [Continuous integration with GitHub Actions](https://nix.dev/guides/recipes/continuous-integration-github-actions) [Setting up distributed builds](https://nix.dev/tutorials/nixos/distributed-builds-setup) Deployment tools: [colmena](https://github.com/zhaofengli/colmena), [deploy-rs](https://github.com/serokell/deploy-rs), [comin](https://github.com/nlewo/comin) [Forgejo Actions Reference](https://forgejo.org/docs/next/user/actions/reference/) [NixOS deployment: from push to pull](https://lewo.abesis.fr/posts/from-push-to-pull-deployment/) [Remote deployment NixOS & Flakes Book](https://nixos-and-flakes.thiscute.world/best-practices/remote-deployment) [CI/CD rebuilds via github](https://discourse.nixos.org/t/ci-cd-rebuilds-via-github/36059)