Author Here. Thanks for reading. I am not trying to be misleading. I'm trying to point out that although each step along the way of adding things to config seems to make sense, you arrive in a bad place.
People start with some YAML, and everything is fine. Then a simple condition is added, so ok, we are treating code as data, LISP style but in YAML. Then the logic and branching grows, and we introduce templates and so on.
You start with config, then the config ends up with its own config, and eventually, you are using Skaffold to configure Helm, which generates your YAML. That can't be the right solution, can it?
The point is that CI workflow orchestration and clustered application deployment definitions are not config, at least not in the same way as “here is some hierarchy of definitions that change the behavior of an application.” These are attempts to create declarative DSLs that script workflow steps. In the Helm case specifically, the templating engine produces yaml because Kubernetes uses yaml for its manifests, and Kubernetes uses yaml for manifests because it provides a one to one mapping to the actual data structures used by the cluster manager. It’s way beyond config. You’re defining the entire state of a clustered application, including the infrastructure. Only the Values.yaml is config and I don’t see how that alone is all that complicated.
People start with some YAML, and everything is fine. Then a simple condition is added, so ok, we are treating code as data, LISP style but in YAML. Then the logic and branching grows, and we introduce templates and so on.
You start with config, then the config ends up with its own config, and eventually, you are using Skaffold to configure Helm, which generates your YAML. That can't be the right solution, can it?
https://skaffold.dev/docs/pipeline-stages/deployers/helm/