Is it actually possible to just have the YAML that calls into your app today, without losing the granularity or other important features?

I am not sure you can do this whilst having the granular job reporting (i.e. either you need one YAML block per job or you have all your jobs in one single 'status' item?) Is it actually doable?

You don't have to reason about them.

You write a compiler that enforces stronger invariants above and beyond everything is an array/string/list/number/pointer.

Good general-purpose programming languages provide type systems that do just this. It is criminal that the industry simply ignores this and chooses to use blobs of YAML/JSON/XML with disastrous results---creating ad-hoc programming languages without a typesystem in their chosen poison.

I've done exactly this a few times... ensure my scripting host is present then use scripts for everything. I can use the same scripts locally without issue and they work the same on self-hosted runners.

Note: mostly using Deno these days for this, though I will use .net/grate for db projects.

> If it was so easy you could just do it now.

Some do just that: dagger.io. It is not all roses but debugging is certainly easier.

There is a battle tested example of YAML vs programming languages in CloudFormation templates vs CDK.

I don't think anybody serious has any argument in favor of CloudFormation templates.

> If the system consuming the YAML supports in-band signalling -- i.e. proprietary non-YAML directives -- then you would need to first normalize the YAML using that system to interpret and expand those signals.

cough CloudFormation cough

HCL is same s**, different smell. Equally hamstrung. It’s the reason hashicorp came out with an actually programmable version of the hcl semantics: CDKTF.

If you have worked with HCL in any serious capacity, you'll be happy they didn't go that route.

Here's some fun examples to see why HCL sucks:

- Create an if/elseif/else statement

- Do anything remotely complex with a for loop (tip: you're probably going to have to use `flatten` a lot)

Hey. I'm currently making Typeflows to solve this (amongst) another few pain points, and am planning to make it available in JVM (this exists now)/TS and Python at least.

There are existing solutions around, but do miss out a bunch of things that are blatantly missing in the space:

- workflow visualisations (this is already working - you can see an example of workflow relationship and breakdowns on a non-trivial example at https://github.com/http4k/http4k/tree/master/.github/typeflo...);

- running workflows through an event simulator so you can tell cause and effect when it comes to what triggers what. Testing workflows anyone? :)

- security testing on workflows - to avoid the many footguns that there are in GHA around secrets etc;

- compliance tests around permitted Action versions;

- publishing of reusable repository files as binary dependencies that can be upgraded and compiled into your projects - including not just GHA actions and workflows but also things like version files, composable Copilot/Claude/Cursor instruction files;

- GitLab, CircleCI, Bitbucket, Azure DevOps support using the same approach and in multiple languages;

Early days yet, but am planning to make it free for OSS and paid for commercial users. I'm also dogfooding it on one of my other open source projects so to make sure that it can handle non-trivial cases. Lots to do - and hopefully it will be valuable enough for commercial companies to pay for!

Wish me luck!

https://typeflows.io/

It has pricing tiers!? That's crazy, just use https://www.npmjs.com/package/github-actions-workflow-ts

Website barely loads on my old phone and I can't see any examples of the syntax.

> prioritise being able to run them locally.

That is the key function any serious CI platform needs to tackle to get me interested. FORCE me to write something that can run locally. I'll accept using containers, or maybe even VMs, but make sure that whatever I build for your server ALSO runs on my machine.

I absolutely detest working on GitHub Actions because all too often it ends up requiring that I create a new repo where I can commit to master (because for some reason everybody loves writing actions that only work on master). Which means I have to move all the fucking secrets too.

Solve that for me PLEASE. Don't give me more YAML features.

YAML is neither declarative nor imperative. It's just a tree (or graph, with references) serialization to text.

Well, Groovy is a bit of a basket case programming language, so that doesn't help.

I say this as someone that built entire Jenkins Groovy frameworks for automating large Jenkins setups (think hundreds of nodes, thousands of Jenkins jobs, stuff like that).

I work on a monorepo that does this using Typescript, for type checking. It's a mess. Huge learning curve for some type checking that very often will build perfectly fine but fail a type-check in CI.

Honestly, just having a linter should be enough. Ideally, anything complicated in your build should just be put into a script anyways - it minimizes the amount of lines in that massive YAML file and the potential for merge conflicts when making small changes.

YAML is a serialization format. I like YAML as much as I like base64, that is I don't care about it unless you make me write it by hand, then I care very much.

GitHub Actions have a lot of rules, logic and multiple sublanguages in lots of places (e.g. conditions, shell scripts, etc.) YAML is completely superficial, XML would be an improvement due to less whitespace sensitivity alone.

Sure, easy to read, but quite difficult to /reason/ about in your head, let alone have proper language server/compiler support given the abstraction over provider events and runner state. I have never written a CI pipeline correctly without multiple iterations of pushing updates to the pipeline definition, and I don't think I'm alone on that.

Easy to write and read until it gets about a page or two long. Then you have to figure out stuff like "Oh gee, I'm no nesting layer 18, so that's... The object.... That is.... The array of.... The objects of....."

Plus it has exactly enough convenience-feature-related sharp edges to be risky to hand to a newbie, while wearing the dress of something that should be too bog-simple to have that problem. I, too, enjoy languages that arbitrarily decide the Norwegian TLD is actually a Boolean "false."

> Easy to write and read by hand, while also being easy to write and read with code in just about every language

Language implementations for yaml vary _wildly_.

What does the following parse as:

    some_map:
      key: value
      no: cap

{'some_map': {False: 'cap', 'key': 'value'}}

The other gives me:

{'some_map': {'false': 'cap', 'key': 'value'}}

... and neither gives what a human probably intended, huh?

It's less about YAML itself than the MS yaml-based API for interacting with build-servers. It's just so hard to check and test and debug.