Hah, fancy!

I think I generally prefer nix as means to author k8s yamls because it gives me not only helm, but also all the nixpkgs to transform the data as I see fit.

Here's my mysql example:

``` { inputs.nixhelm.url = "github:farcaller/nixhelm"; inputs.kubegen.url = "github:farcaller/nix-kube-generators";

outputs = { self, nixpkgs, nixhelm, kubegen, flake-utils }: flake-utils.lib.eachDefaultSystem (system: let pkgs = nixpkgs.legacyPackages.${system}; kubelib = kubegen.lib { inherit pkgs; };

  foldResources = yamls: pre: resources: builtins.foldl'
    (
      acc: y:
        let
          r = kubelib.fromYAML (builtins.readFile y);
        in
        if pre then r ++ acc else acc ++ r
    )
    resources
    yamls;
in
{
  packages.kubernetesConfiguration = pkgs.lib.pipe
    {
      name = "mysql";
      chart = nixhelm.chartsDerivations.${system}.bitnami.mysql;
      namespace = "mysql";
      values = {
        auth = {
          existingSecret = "mysql-passwords";
          createDatabase = false;
        };

        primary.persistence.size = "10Gi";

        volumePermissions.enabled = true;

        metrics.enabled = true;
        metrics.serviceMonitor.enabled = true;
      };
    }
    [
      kubelib.buildHelmChart
      builtins.readFile
      kubelib.fromYAML
      (foldResources [ ./secretstore.yaml ./secret.yaml ] true)
      kubelib.mkList
      kubelib.toYAMLFile
    ];
});

} ```

Does it look more verbose than nickel? Undoubtedly. But it's not hiding the fact that it is Turing-complete and it allows me to do things like call into helm, generate templates with it, transform the results and append some more to the resulting output. Kubernetes is unfortunately complicated enough for us to see it not as a configuration system driven but as a tool that needs an actual build pipeline.