[huem0n]

Yeah theres some problem, but reading a multiline code block (like github actions bash script) as an indent-escaped string is so much better than having to understand crazy triple-escaped characters like "sed \"\\\\\\"name1\\\\\\\"\""

[stevage]

What's even better is just using an actual programming language. Not bash, not sed, not yaml. Just python or NodeJS.

[mdaniel]

This is the same debate folks have between Maven and Gradle: do you want CI code to be able to do *anything* that Python or Node can do, or do you want well defined knobs people can turn. If nothing else, it makes code reviews for CI way less drama than trying to use some bespoke dsl-in-python that re-implements {job: {steps: [{run: ...}]}} in a less legible way

[stevage]

Yeah. My experience has often been that you end up with a task that is very easy and familiar to write in say Bash, that you then have to solve a puzzle to write in Ansible/Puppet/whatever. Which feels exactly like what you're saying: a DSL re-implementing something else in a less legible way.

I guess it's like anything: for the right task, the right tool works well. But invariably, a tool will eventually be pushed into use for the wrong task.

[theamk]

you only think until you have to extract some information from it. "Here is a dir full of CI job definitions, find all the ones which require extra permissions" - trivial in yaml or json or toml, could be hard to impossible for Python/nodejs.

or "I am doing ci job frontend, for each job I need to get a list of inputs it takes and their description, but without doing full code checkout" - good luck doing this if your jobs are in python/nodejs.

(to be fair, there are programming languages that are also severely limited and can be evaluated mostly safely, like Starlark, but I don't think they'd match your definition)