> If you're using things which do macro expansion or anything else that involves you writing format A and it generating format B which actually does the work (or worse yet, gets turned into format C), you really owe it to yourself to run a 'diff' on the before-and-after versions of the output from the tool BEFORE it goes and takes any action on your behalf.
Seriously. This is a huge issue with Helm templating Kubernetes resources definitions. When you make a PR on your infrastructure repository, there could be many changes underneath the hood in a Helm chart that Are invisible from changes to a values file.
We had a rule in my last job the diff of the actual resource files had to be included in the PR in order to be approved because we were bit by the same.
We're probably going to be moving to a K8s thing, and this what I'm most scared of, really. This kind of macro expansion is (to me) a huge red flag wrt. understandability, audits, etc. It's really just an indicator of a lack of composability. Yeah, you can try to add it, but that doesn't really work (see Ansible.)
Ideally, I'd want something like Propeller (with static type checking) to actually have a little confidence in my changes. We're not using Propeller due to the fact that it requires/installs GHC on the target machines -- I wish there was a GHC-to-bash compiler...
Seriously. This is a huge issue with Helm templating Kubernetes resources definitions. When you make a PR on your infrastructure repository, there could be many changes underneath the hood in a Helm chart that Are invisible from changes to a values file.
We had a rule in my last job the diff of the actual resource files had to be included in the PR in order to be approved because we were bit by the same.