3 ms·

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.

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.

evfanknitram 8y ago
And then you end up with something like: https://docs.saltstack.com/en/latest/topics/jinja/index.html https://docs.saltstack.com/en/latest/topics/jinja/index.html
crdoconnor 8y ago
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.
- amelius 8y ago
  Yes: https://news.ycombinator.com/item?id=17529747 https://news.ycombinator.com/item?id=17529747
scarface74 8y ago
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.
- jdi92 8y ago
  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.
  - scarface74 8y ago
    Exactly. Why would I want to learn another pseudo scripting language when I have Powershell, bash, Python, etc at my disposal?
KaiserPro 8y ago
"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?
- oweiler 8y ago
  Groovy based declarative pipelines were also version-controlled, stable and repeatable.

evfanknitram 8y ago

And then you end up with something like: https://docs.saltstack.com/en/latest/topics/jinja/index.html https://docs.saltstack.com/en/latest/topics/jinja/index.html

crdoconnor 8y ago

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.

amelius 8y ago
Yes: https://news.ycombinator.com/item?id=17529747 https://news.ycombinator.com/item?id=17529747

scarface74 8y ago

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.

jdi92 8y ago
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.
- scarface74 8y ago
  Exactly. Why would I want to learn another pseudo scripting language when I have Powershell, bash, Python, etc at my disposal?

KaiserPro 8y ago

"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?

oweiler 8y ago
Groovy based declarative pipelines were also version-controlled, stable and repeatable.