* 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.
I'm guessing this got dropped again as part of having multiple
branches in flight and rebasing. It would be good if CI checked that
`npm install` and `npm run build` resulted in *zero* diffs to validate
that generated/lock files match their source at time of CI.
Use the GitHub Actions-issued JWT to authenticate with FlakeHub.
The repository will be granted its due permissions on FlakeHub,
and be able to pull the user's private flakes.
