Vals errors should abort kubectl apply

[pizzapim]

If Vals reports an error when replacing secrets refs, the kubectl apply should not be executed.

Here is an example. I have a Kubernetes secret with a Vals ref that is broken (the file does not exist).

{
    kubernetes.resources.secrets.freshrss.stringData.adminPassword = "ref+sops://secrets.yaml#/freshrss/password";
}

Rendering this shows that Vals tries to expand the secret ref, but fails opening the file:

$ nix run .#kubenix.x86_64-linux render
expand sops://secrets.yaml#/freshrss/password: Failed to read "secrets.yaml": open secrets.yaml: no such file or directory

However, when I then try to apply the Kubenix configuration, I expect it to fail as well which it does not:

$ nix run .#kubenix.x86_64-linux
expand sops://secrets.yaml#/freshrss/password: Failed to read "secrets.yaml": open secrets.yaml: no such file or directory
W0414 14:30:40.686142 2206795 prune.go:71] Deprecated: kubectl apply will no longer prune non-namespaced resources by default when used with the --namespace flag in a future release. To preserve the current behaviour, list the resources you want to target explicitly in the --prune-allowlist flag.
diff -N -u -I ' kubenix/hash: ' -I ' generation: ' /run/user/1000/LIVE-1858589435/v1.PersistentVolume..bazarr-config /run/user/1000/MERGED-859534972/v1.PersistentVolume..bazarr-config
--- /run/user/1000/LIVE-1858589435/v1.PersistentVolume..bazarr-config   2024-04-14 14:30:40.710017293 +0200
+++ /run/user/1000/MERGED-859534972/v1.PersistentVolume..bazarr-config  1970-01-01 01:00:00.000000000 +0100
@@ -1,90 +0,0 @@
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  annotations:
-    kubectl.kubernetes.io/last-applied-configuration: |
...

It reports the error, but continues anyway. The "result" of Vals is an empty manifest, which then causes kubectl apply to prune all of my existing resources.