5 ms·
YAML seems reasonable because it allows the sequence of steps to be treated as data, which then enables GUI visualisation, introspection, etc... without actuall
by jiggawatts 2mo ago
YAML seems reasonable because it allows the sequence of steps to be treated as data, which then enables GUI visualisation, introspection, etc... without actually having to run anything.
That's critical for a platform like GitHub and for devops pipelines in general.
The failure is that "data" ends up being a "terrible custom DSL" that is bad at everything: Not good at data, not a good DSL, and not even a proper programming language.
The best approaches I have seen to this kind of thing are:
- Pulumi: You get to run custom code, but it outputs data. In other words, your "build automation script" must be a pure function taking data in and returning data out. The resulting data is then treated as the "thing" that the pipeline executes, which means that all decisions (parameters, inputs, etc...) have to be "baked in", before the pipeline starts executing.
- Google CUE (Configure Unify Execute): lets you build up JSON using a strongly typed constraint language. Great for huge, complex configuration.
- verdverm 2mo agonit, CUE is independent from Google now, Marcel left to work on it full time years ago with some other folks, they started a company
- frollogaston 2mo agoThe best thing I've seen is just regular JS or Python that outputs some data like JSON or protobuf. Google has a ton of DSLs that do this too, problem is they're DSLs and about 4 people fully understand them.
- saghm 2mo agoMy point wasn't that YAML is an indefensible choice, but that embedding bash inside the YAML is at least to me not defensible. Making the `run` field take a string that's treated as a path to script within the repo would still give you all of the properties of "this config is data" without any of the nightmares that comes to multiple stacked layers of string interpolation in languages that are each already notorious for bugs from that sort of thing.