Having this option available allows for using a flake which isn't in (or
upwards of) the directory the command gets executed in and allows for
using remote flakes.
Also archive the flake to use first and then operate on the archive.
This allows for easily getting the deployment_configuration.json from
the archive and also ensures that once the archiving suceeds, there
shouldn't be issues with the flakes source anymore.
Since now the deployment_configuration.json will always be taken from
the root of the flakes archive and therefore from the root of the flakes
repo, this is a breaking change, since previously it was taken from the
current working directory.
The idea of archiving the flake first and operating on the archive comes
from bij:
221052d846
Moreover introduce helper functions for facilitating recursive options
(i.e. options one can set on root and sub-commands).
Also make the "reboot" operation basically an alias for "boot --reboot"
then and simplify the code of the operations.run function, since it
doesn't need to convert between operation and actual_operation anymore.
Since the hosts are what nixos-rebuild acts on it makes to have them
represented by unlimited variadic arguments similar to how "git add",
"cat", "nix build", etc. work.
Redefine the commit message "update" tag to be for tagging an
enhancement or update, which doesn't qualify as a feature, and also have
it not be restricted from tagging a breaking change.
Do this for a nicer developer experience in a safer language, which has
nice libraries available to e.g. build command line interfaces (e.g.
click).
Set minimum Python version to 3.10 to support match statements.
Create a skeleton python project using "hatch new -i --cli
infra-rebuild" with Hatch version 1.7.0 and modify it to fit this
project. This is the first step of porting infra-rebuild to Python.
Also provide a first .gitignore ignoring relevant build directories.
infra-rebuild is a simple NixOS deployment tool, which simply uses
nixos-rebuild internally, but tries to make it more convenient to deploy
infrastructure.
It supports most of the nixos-rebuild operations - build, build-vm,
build-vm-with-bootloader, switch, boot, test - but also provides a
reboot operation, which runs nixos-rebuild boot followed by initiating a
reboot.
The tool doesn't need any configuration for a standard use case. It
tries to get the hosts FQDN from its NixOS configuration and tries to
deploy to it. However for special cases, where a custom target hostname,
user or port is needed, it allows one to define those in a
deployment_configuration.json.
infra-rebuild also allows for multiple hosts to be specified at once.
The tool then simply runs the specified operation for each host
sequentially.
Much inspiration was taken from bij.
See here: https://git.clerie.de/clerie/bij
And inspiration was also taken from Colmena.
See here: https://github.com/zhaofengli/colmena
June