there is a recurring pattern in infrastructure tooling. a tool starts simple, uses a config file, and then the config file slowly becomes a programming language. except it's a bad programming language, because it's YAML.
i call this the YAML trap. it goes like this:
step 1: "we just need a simple config file." you write 20 lines of YAML. it's clean and readable. life is good.
step 2: "we need conditionals." someone adds if expressions to the YAML. now you have a config file with control flow. the syntax is awkward but manageable.
step 3: "we need templating." someone adds variable substitution, loops, and includes. your YAML file is now a program, but without a debugger, a type system, or syntax highlighting that understands what it's doing.
step 4: "we need a way to test our configs." congratulations, you've reinvented programming. except your programming language is YAML with extra steps, and it's worse than every real programming language in every measurable way.
the escape
the moment your config file needs conditionals, it's time to use a real programming language. not because YAML is bad at being YAML. it's fine for static configuration. but YAML is terrible at being a programming language, and the transition from "config" to "program" is always gradual enough that you don't notice until you're deep in it.
tools like Pulumi (real code for infrastructure) and CDK (same idea, AWS flavor) got this right. your infrastructure definition is a program? use a programming language. you get type checking, IDE support, testing, and all the other things we figured out decades ago.
status: this note exists because i spent four hours debugging a GitHub Actions workflow and needed to vent. the argument still holds.