> I hate, on a fundamental level this whole "bash in YAML" trend.

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)

I'll take writing stuff in YAML (Ansible) over all of the complexities and performance issues Chef brings. At megacorp a lot of my peers still hadn't let go of the button pusher mentality and were both inexperienced at coding and skeptical of automation. The problem with the power of ruby (as Chef exposes it) is that you've got the power of ruby aimed right at your foot.

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.

So... Nix?

https://nixos.org/nixos/about.html

I really don't understand why people are so reluctant to use Tcl for these kinds of things.

> If only there were some language where config data and code were the same data structure. (hmmmmmm)

Instantly reminds me of SICP and Lisp, code is data.

> If only there were some language where config data and code were the same data structure. (hmmmmmm)

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.

I am pretty sure Lisp was wedged into some places where it is a poor fit, but “lots”? Did you guess Javascript by any chance?

I did guess Javascript, as it happens.

Was I wrong? If it was meant to be a reference to Lisp, I take much of it back.

The parent was most likely referring to lisp, but note that there are other homoiconic [1] languages.

[1] https://en.m.wikipedia.org/wiki/Homoiconicity

you can write python plugins and modules to extend functionality, there is no need to just start running commands everywhere.

AWS CDK seems nice

GitLab CI/CD product director here - we're working towards making includes more flexible to give you a lot more control. Would love your feedback on the small primitives we're looking at here: https://about.gitlab.com/direction/cicd/#powerful-integrated...

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.

> 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_.

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 could use a build system to build .gitlab-ci.yml from many source configuration files, and a build system to build the configuration for the build system that builds the configuration for your build system, and...

Gitlab lets you run any step with a different docker base image. How about instead of bash scripting in the yaml, you just put scripts, in any language, in a docket file, and simply use bash to call those scripts. The gitlab yaml is not designed for you to code in, bash is just a standard interface for calling into other things.

This is what I’ve been doing lately. It has the advantage of being able to run the scripts without GitLab CI.

With newer versions you can include other yaml files.

You can also have templates, special jobs starting with dot.

> With newer versions you can include other yaml files.

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