ocurrent VS automate

Y axis is tool selection. Positive region of axis is “use a DSL”, lower region is “use a GeneralPurposeProgrammingLanguage”

The line starts at the origin, has a SMALL positive bump, than plummets downwards near vertically.

Gets it right? Tools like ocurrent (contrasted against GH actions) [1], cdk (contrasted against TF yaml) [2]

Gets it wrong? Well, see parent post. This made me so crazy at work (where seemingly everyone has been drinking the yaml dsl koolaide) that i built a local product simulator and yaml generator for their systems because “coding” against the product was so untenable.

[1] https://github.com/ocurrent/ocurrent/blob/master/doc/example...

Keep working on this. It’s a splendid idea. Would be cool to eventually have a recipe where you import the crate, then program the deploy in rust, invoking your tool which builds my-build.rs, or a proper cargo build.

The following not true apples to apples, but pretty close. Rather than another crummy stringy DSL, the ocaml community said “we want to program our CI pipelines in OCaml”. So, they created https://github.com/ocurrent/ocurrent. You build your pipeline in an incredible language—then the CI server simply invokes your pipeline code, assuming you’ve implemented a basic interface.

> For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

For running scripts from a library, I've used ByJG's automate.sh[1] that call'em recipes. Unlike z-run, they're bash only and there's no select menu and looks simpler.

[1] https://github.com/byjg/automate