yaml2json and json-to-ts-cli are useful

isn't this going to result in us being the Chef of ".dotfiles" for projects? we'll always be behind. This is why JSII generates from CFT weekly right ?

I've been mostly thinking about the workflow schema, not actions...

I think the basic schema for GitHub workflows is not going to dramatically change, so it's probably not too much of a maintenance effort to add new features as they emerge. We should also include an "escape hatch" for users to be able to break the abstraction (of course).

@eladb are you suggesting modeling this down to the granularity of Events, ActivityTypes, etc? e.g. webhook-events

All the way down. The more we model the more users would love this

Cool. I love it. I'm going to give it a shot if you don't mind.

I'm not intimately familiar with Workflows yet, so this is a slightly selfish chance to gain that knowledge. :D It'll take me a while to get through the docs, but I'll try to post a PR once I get the top-level classes done to get some feedback.

@pgollucci I like the idea of generating these types, I've explored this a bit in a project on my own. https://www.schemastore.org/json/ has Github Workflow and Github Actions schemas (and many more). Generating types from these using something like json-schema-to-typescript on a weekly cadence would offload the maintenance effort

@jackdreinhardt, schema-driven definitions would be awesome. I started down that road with modeling workflows, but quickly found that the half-dozen or so jsonschema to TS conversion libraries I tried all behaved radically differently. They also all lacked core schema feature support to produce useful output for this complex of a schema.

In experimenting with the conversion libs, how did you get around them not supporting certain schema keywords?

My impression so far is that we want more than just types, so that's how I'm proceeding right now. I share concerns about modeling a schema that may change, but also share Elad's perspective that the schema is not likely to change radically. Provided appropriate escape hatches are in place, folks should be able to adopt new features before they're officially modeled.

@gradybarrett I didn't run into too many issues with unsupported keywords - I was working with the gitlab-ci schema, not Github WF. But where I did, I ended up having to modify the output (kind of defeats the purpose of a converter). I agree with you: none of the current converters are perfect, esp when considering the complexity of these schemas.

I think these should stay on the radar though. If a library improves to the point where all the boxes are checked for generating the types/L1 elements, it would be pretty sweet to do so. Until then, escape hatches will cover this use case just fine

I think these should stay on the radar though. If a library improves to the point where all the boxes are checked for generating the types/L1 elements, it would be pretty sweet to do so.

100% agree.

This issue is now marked as stale because it hasn't seen activity for a while. Add a comment or it will be closed soon.

Implemented by @RomainMuller