zlacker

>>marius+(OP)
I just want to be able to write all my workflow code as typescript (including the config - no YAML, for the love of god, no more YAML!) and run it locally with a debugger attached.

It's cost me hundreds to thousands of dollars to implement nontrivial workflows because of how the YAML is parsed (for example, empty strings when using a secret that has been renamed or removed) and the lack of introspection or debuggability when something goes wrong.

It's gotten to the point where new any new workflows I write are thin wrappers around a single script and I don't import any actions besides actions/checkout (even that has been bug prone, historically).

All that said, it's not like other platforms are better. But they certainly are cheaper and don't have dumb breakages when you need cross platform builds (has upload-artifact been fixed for executables on MacOS yet?)

>>duped+Rl
This is exactly what I'm working on at https://www.inngest.com. You can write statically typed workflows, run any code as an action (if it runs in a container, or use lambda otherwise), have complex conditionals, and coordinate between events (eg. pause until an event comes in that matches a condition, with TTL paths). There's a debugger to step-over workflows, and see the input/output as it happens. Coming soon, the ability to run actions locally during debug mode.

Workflows are statically typed in that they have event triggers - ideally with an event schema (which we generate for you) - and each "action" has static typing of inputs/outputs (plus additional workflow configuration for reusability). They're defined as code, and can be viewed or edited visually.

It also bundles an event hub, so you can automatically run workflows when events happen in real time. For example, if you want to run a churn flow on signup, create a workflow with a `signup.new` event trigger. The workflows can also coordinate between events, too, so in the churn workflow you can wait for an "interactivity" event from the user for up to 1 day, then time out and run some other flow/logic.

It's workflows, generalised. As if you put Github Workflows, Lambda, Segment, and Zapier in a blender.

If you want early access, you can always reach me at tony [at] inngest.com. I'm rolling out invites every week.

>>tonyhb+8R
Do you have clients using this for CI/CD? It looks very interesting, if a bit more general-purpose.

>>pc86+xV
CD (including ourselves), operational pipelines, sales pipelines, internal events/logic, scheduled flows, and machine learning are a few of the areas I'm seeing.

CI isn't _necessarily_ our current target. As of yet, there's no concept of "failed runs" in the classic CI sense. We highlight failed workflows but will retry actions by default. If things fail, we allow you to retry/edit the data, debug in line, etc.

It's definitely possible to use the failed workflow runs as a CI pipeline, but the UX would need an overhaul. Right now, we do user-event attribution to show you which workflows users are running in your system, their version, and the steps - which is needed for actual, live system workflows vs CI workflows.