* Rebase on top of detsys-ts for abstracting over install.determinate.systems
* Support the legacy nix-installer-xxx source prefs
* Document source-* opts
* Update deps
* cut duration so it doesn't take forever
* Move the complete step into a finally block
* Test a busted run
* come on ...
* update to the main detsys-ts
* Switch to the delegated execution model
* throw an error to check behavior
* Fixup lint errors
* Drop the forced error
* Share /bin with nix for post-build-hooks
* test the magic nix cache
* wtf
* permissions
* Share /home and the network namespace too
* test the devshell
* Don't force-set kvm to 0 ... d'oh!
* dev shell support for aarch64-linux
* ?
* More testing / debug
* Make it run anyway
* Bind /lib too so /bin/sh works ... sigh
* Disable gha-cache for tesing
* Kill the magic nix cache before reinstalling
* Don't set the extra environment variables extraniously
* Enable gha cache again
* Test nix-installer-action on Namespace.so
It is special in that it doesn't have systemd, and it'd be great to
support Namespace.so. It is also a good test case for a variety
of self-hosted GHA runner use cases.
* Make correlation more confident
* Borrow docker as a process supervisor on Linux GHA runners without systemd
This change introduces a Docker container shim which spawns the Nix
daemon after bind mounting all the relevant paths into the container.
The image is actually completely empty, other than metadata about what
to run.
This is a cheap and cheerful way to get decent process supervision in
environments that don't bring systemd, but do have docker ... which
is most everywhere in the GHA ecosystem.
* Ignore generated files
* Run on arm64 why not
* Load a pre-built image, don't build
* Check the userInfo.username instead of an env var
* Stop double-printing output to the console
* can't rm and restart
* what
* Clean up the container at the end
* Emit the fetch line in the 'installing nix' section
* tweak output
* delete what
Background: Namespace managed runners run each github job in a container, in a
separate micro-vm managed by Namespace. These VMs and containers do not rely on
systemd, and instead use Namespace's own init/process management.
