nixosConfiguration support for std-action
cellBlocks = with hive.blockTypes;
[ (nixosConfigurations // { ci.build = true; })`
Doesn't generate enough details for std-action (missing proviso / drvPath attrs in nix eval .#__std.ci.x86_64-linux.)
Is this out of scope since it falls outside the cell block's scope (harvest/collect/transform)?
I'm not familiar with the internals of std/hive, but happy to implement it if someone can guide me!
This shouldn't fall out of scope.
If there's no kvm build necessary, it should even build on GitHub actions.
The nixos blocktype is implemented here, so any modification to the blocktype necessary to be eligible for std-action needs to go there: https://github.com/divnix/hive/blob/main/src/blockTypes/nixosConfigurations.nix
Proviso should be optional: https://github.com/divnix/std-action/blob/4d88d45cacadad99e60218b4ed83037a5884a33c/discover/eval.sh#L54 — but it can be implemented so as to avoid building a nixos build twice, since the only reasonable "registry" of a finished build is the cache, we can use the normal nix build proviso: https://github.com/divnix/std/blob/main/src/std/fwlib/actions/build-proviso.sh
While actionDrv is the wrapping script that is executed locally / or by the final step, targetDrv is the main build artifact wrapped into the actionDrv, for example:
❯ nix build '.#__std.actions.x86_64-linux."david"."nixosConfigurations"."meerkat"."build"'
❯ cat result
#!/nix/store/gwgqdl0242ymlikq9s9s62gkp5cvyal3-bash-5.2p37/bin/bash
bin=$(nix build .#nixosConfigurations.david-meerkat.system --no-link --print-out-paths)/sw/bin
export PATH=$bin:$PATH
nixos-rebuild build --flake "$PRJ_ROOT" $@
In that actionDrv wrapper, nixosConfigurations.david-meerkat.system would be the targetDrv, which btw seems a bug. It should be nixosConfigurations.david-meerkat.config.system.build.toplevel, ergo nixosConfigurations.david-meerkat.config.system.build.toplevel.drvPath which according to above paisano-nix/core link should be drvPath-collected from the target, if the target is set correctly (which thangs to the apparent bug does not seem the case, here).
You can check out what the target holds in the nixosConfiguration block type, but since the actual nixosConfigurations are located elsewhere in the tree (namely under .nixosConfiguration) rather than directly under the cell block, we might still continue to reconstruct the path with regard to the entire flake as we do now and can't work with target directly. Still, we can extract the targetDrv from drvPath and assign it manually to the action output (iirc as sisters to the command attribute).
Thanks @blaggacao for the detailed explanation! Let me give this a shot and prepare a PR
For now, my approach would be
- Pass
.#nixosConfigurations.${hostname}.config.system.build.toplevel.drvPathas drvPath - New proviso script, as the existing one in std relies on
nix-store --realise --dry-run /nix/store/***.drvand can't use the format in step 1.