one of the advantages of using a declarative “non executable” format like yaml for configuring ci (and other things, like k8s definitions, for example) is that every execution using that declarative artifact should be deterministic. all i as a user need to do is read that file. obviously you can violate this in various ways by introducing directives that read other files or env vars or via tools that use directives to do inherently non-deterministic things (like reading from external state store) but the potential misuse is limited in scope to what the tool and the “magic” directives introduce
by going to a fully imperative, unconstrained language for ci like elixir, now the opportunity to do misguided things is ramped way up. we saw this in mix configs where users introduced problems by making calls in their configs that caused issues in different execution environments. for example, reading from an env var that was present in dev but not prod or by trying to read from files not present in the build artifact. often this was done not out of a concious decision to introduce those issues but out of ignorance or – worse – out of an increase in complexity that was not really tractable to understand. using a first class programming language for ci is going to lead to many of the same problems
contrast with something like dhall. dhall is a language for generating declarative configurations. it offers most of what you expect from a programming language (functions, variables, libraries) but introduces the constraint that you can’t do any i/o (outside of very constrained things, like including other files in a static manner). this means that every execution is deterministic with regards to it’s initial inputs (the set of files it reads). the same files on any host will produce the same outputs
i get the desire to not introduce new concepts and new tooling and i am 100% in agreement that a lot of the “yaml as program” pattern is terrible, but i think embracing programs as configuration is the wrong direction
