cli: separate nix rule for cli release build

We would like to include a standard coordinator policy hash into cli
releases, so that the coordinator can be deployed separately and is
still verified by the cli.

We cannot embed a default coordinator policy into the existing build
rule:

* To generate a policy hash, we need to build the coordinator, publish
  it as an OCI image and run genpolicy on it.
* To embed the hash in the binary, it needs to go into  the build inputs.
* If it's in the build inputs, the output store location changes.
* If the output store location changes, the OCI layer (and thus the
  required policy) changes.

On the other hand, we would like to keep the multi-binary build rule for
development, so we introduce a new build rule exclusively for cli
releases, and only that rule consumes the coordinator policy hash as
input.

Co-authored-by: Paul Meyer <[email protected]>

cli/assets/coordinator-policy-hash

@@ -0,0 +1 @@
+0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

cli/runtime.go

@@ -3,4 +3,4 @@ package main
 // DefaultCoordinatorPolicyHash is derived from the coordinator release candidate and injected at release build time.
 //
 // It is intentionally left empty for dev builds.
-var DefaultCoordinatorPolicyHash = "" // TODO(burgerdev): actually inject something at build time.
+var DefaultCoordinatorPolicyHash = ""

packages/default.nix

@@ -34,7 +34,7 @@ rec {
     let
       subPackages = [ "coordinator" "initializer" "cli" ];
     in
-    buildGoModule {
+    lib.makeOverridable buildGoModule {
       inherit version subPackages;
       name = "nunki";
 
@@ -77,6 +77,12 @@ rec {
     };
   inherit (nunki) cli;
 
+  cli-release = (nunki.override (prevArgs: {
+    ldflags = prevArgs.ldflags ++ [
+      "-X main.DefaultCoordinatorPolicyHash=${builtins.readFile ../cli/assets/coordinator-policy-hash}"
+    ];
+  })).cli;
+
   coordinator = dockerTools.buildImage {
     name = "coordinator";
     tag = "v${version}";