> The common CI spec is sh & make, but everybody hates those I guess. These aren't very good at some of the things you actually want to use a CI for, other tha

> The common CI spec is sh & make, but everybody hates those I guess. These aren't very good at some of the things you actually want to use a CI for, other than the literal "build" step (which probably is using them anyway, or the per-language equivalent). Coordinating _and visualising_ multiple builds where some parts run in parallel (e.g. multiplatform), or parts that might be different or skipped depending on how the flow was triggered. Managing caches and artifacts between stages and between runs. Managing running in different contexts, including generic shell and across multiple machine types. A consistent way to manage and inject secrets. Reusing common parts across different CI workflows. I suppose you could have a parent job taking up a full slot to run a Makefile that launches and manages the running of jobs on other nodes, but imagine you'd have to step into some toolset that abstracts some of it, and hope that is shared development or you end up with an in-house convoluted nightmare of shell scripts. "Something DAG and yaml shaped" is about the closest convergence we have gotten, and the closest that it looks like we'll get.