it's wild I can wiz through a ton of code for hours on end but seeing a yaml file for something like a CI pipeline actually makes my brain eject i dunno why. my brain has some sort of proverbial capacity limit with how many different configuration-file looking things I can tolerate in a day, and the prospect of becoming intimately familiar with what is effectively an auto integration presented to me as some sort of config makes me completely unjustifiably butthurt for no reason. have i not suffered enough needless and often times limiting abstractions already

> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement.

Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programming language (unless creating infrastructure is a core part of your software).

> Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.

That's how Drone CI handled it. GitLab kind of does the same, where you always start as a docker image, and thus if you have a custom one with an entrypoint, it does whatever you need it to.

IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess.

YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.

> IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess.

You can have conditions and types without having the full flexibility allowing madness of a full language with HCL.

I've thought about using Pulumi many times. Sounds like dagger.io can be a good complement for the workflow use case?

I enjoy it, but I also think my platform team has set it up in the best possible way. YMMV if it’s done differently- I am sometimes uncertain if I love pulumi, or how we do pulumi.

I really really want to use dagger, but I don’t think there’s organizational interest in it.

Dagger does what you're describing: https://dagger.io/

Neat! Sounds like Pulumi for workflows.

After having to deal with shell rc files causing chaos and unpredictability, I can appreciate your top level code fundamental not being random code but something that is parsable and not subject to the halting problem.