[jayd16]

Why do we think an arbitrary language is easier to reason about? If it was so easy you could just do it now. The yaml could be extremely simple and just call into your app, but most don't bother.

I'm certainly willing to believe that yaml is not the ideal answer but unless we're comparing it to a concrete alternative, I feel like this is just a "grass is always greener" type take.

[ok123456]

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.

[jayd16]

The real issue isn't the code part. You can just call into whatever arbitrary thing you want for the actual script part.

YAML is used for the declarative part of structuring the job graph. The host (in this case, GitHub) would need to call into your code to build the job graph. Which means it would need to compile your code, which means it needs its own build step. This means it would need to run on a build machine that uses minutes because GitHub is not going to just run arbitrary code for free.

There's no guarantee that your arbitrary language is thread safe or idempotent so it can't really run in parallel like how a declarative file could be used.

So now you're in a situation where you add another spin up and tear down step even if your actual graph gen call is zero cost.

There's a reason it works the way it does.

[silverwind]

There is https://github.com/SchemaStore/schemastore which is effectively a type system for yaml/json.

[oblio]

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

https://www.reddit.com/r/funny/comments/eccj2/how_to_draw_an...

[VGHN7XDuOXPAzol]

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?

[iLoveOncall]

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.

[floydnoel]

i might be autistic, but i freakin loved CloudFormation templates. i replaced all the ad-hoc infrastructure in my company with it in less than a year, giving me the ability to spin up production-identical staging environments at-will! never really liked the CDK tho. dunno why

[tracker1]

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.

[esafak]

> 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.