Hacker News Reader

Comment by Chico75 | Hacker News Reader

This is just lowering themselves to the same level as every other CI tool. For sure YAML is an easier barrier to entry to overcome, but it's also a low ceiling.

YAML doesn't let you transcribe logic easily compared to any programming language, and build logic always tends to go up. Programming languages also allows you to create abstraction to remove some of the complexity from the users.

View on HN

And then you end up with something like:

https://docs.saltstack.com/en/latest/topics/jinja/index.html

My experience with yml based builds and deployments is basically using the yml file to tell the build system what code to run to do the build - usually other shell scripts or some other scripting language that can also be in the same git repo.

I read yaml for ansible like an ordered array.

It’s a namespace with the values you want inline, in my head

They’re INI files or .cfg to me

Not code

The code is the Python in Ansible, or Go in TF, that applies those values

Using config mgmt tools like they’re vanilla programming languages is weird.

Exactly. Why would I want to learn another pseudo scripting language when I have Powershell, bash, Python, etc at my disposal?

"This is just lowering themselves to the same level as every other CI tool" you mean making a stable simple and repeatable interface that can be saved in source control?

Groovy based declarative pipelines were also version-controlled, stable and repeatable.

I've been thinking this recently as well. Some problem spaces are definitely very amenable to being transformed into a purely declarative language like YAML but, while builds look like that at first glance, I find that turing-complete-code customization is required just a little too often for it to be worthwhile.

YAML is a way better way of doing it than the current jenkins way though.

Yes: https://news.ycombinator.com/item?id=17529747

Reply on news.ycombinator.com