I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_.
What? I don't even...
And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case.
Sure as shit better than Jenkins though.
This is why I hate Ansible. Looks simple until you need to do something complex, and then it becomes horrible. Chef's use of an actual language is far better, though on the flip side it's much harder to provide any kind of interface to configure it outside of a text editor.
If only there were some language where config data and code were the same data structure. (hmmmmmm)
On top of it, using ruby was a big pain when trying to work with rvm (e.g. for deploying ruby apps or developing ruby apps and running chef commands locally). Things may have gotten better since I last suffered through Chef, but we started running towards terraform + cloudformation.
Instantly reminds me of SICP and Lisp, code is data.
Do you perhaps mean syntax rather than structure? (Or a subset of the syntax.)
If I've guessed correctly, that language has already been wedged into lots of places that it's a poor fit, so I guess there's precedent there.
Was I wrong? If it was meant to be a reference to Lisp, I take much of it back.
This for us represents our vision so far on where we want to take GitLab CI next and I think addresses where you see gaps with our product today - we see them too.
That's a feature. You don't want to reason in Turing languages, you want to reason in a mostly restricted grammar with its Turing-complete escape hatches clearly pointed out.
You can also have templates, special jobs starting with dot.
Where do you see this? Looking at https://gitlab.com/gitlab-org/gitlab-ce/issues/18157 it seems this kind of support is still not started