If you wanted a better version of GitHub Actions/CI (the orchestrator, the job definition interface, or the programming of scripts to execute inside those jobs), it would presumably need to be more opinionated and have more constraints?

Who here has been thinking about this problem? Have you come up with any interesting ideas? What's the state of the art in this space?

GHA was designed in ~2018. What would it look like if you designed it today, with all we know now?

▲

shykes 5 hours ago | parent | next [-]

I've been working for the last 5 years on an alternative called Dagger. Ended up building a company around it.

We started from the ideal state of CI, and set out to build the platform that would support that.

For us this ideal state of CI boils down to 4 things:

- local-first (local execution should be a first-class citizen, with no exception)

- repeatable (the same inputs should yield the same output, with affordances for handling inevitable side effects in an explicit and pragmatic way)

- programmable. my workflows are software. I want all the convenience of a modern software development experience: types, IDE support, a rich system API , debugging tools, an ecosystem of reusable components, etc.

- observable. I want all the information in one place about everything that happened in my workflow, with good tooling to get the information I need quickly, and interop with the existing observability ecosystem (eg. open telemetry)

So Dagger is our best effort at a CI platform focused on those 4 things.

Sorry if this comes across as a sales pitch. When you're building solves a problem you're obsessed with, it's hard to discuss the problem without also mentioning the solution that seems the most obvious to you :)

▲

jgautsch 4 hours ago | parent [-]

I've been watching Dagger with great interest, although have not moved production workloads to it (nor, admittedly, even committed an afternoon to setting up any workflows/graphs).

Passive comment readers should be aware that ^shykes here cofounded Docker (my gratitude), so it's really worth a look.

Can anyone comment on the ergonomics of Dagger after using it for a while?

I was just looking at the docs earlier this week to consider a migration but got confused by the AI sections...

▲

shykes 4 hours ago | parent [-]

> got confused by the AI sections...

You're not the only one... At some point last year, we discovered that CI/CD workflows and so-called "AI agent workflows" have a lot in common, and Dagger can in theory be used as an execution engine for both. We attempted to explain this - "great for CI/CD and for Agents!". But the feedback was mostly negative - it came across as confusing and lacking focus. So, we are rolling back this messaging and refocusing on CI/CD again. If you haven't checked our docs in the latest 12 hours, it's worth checking again: you'll see clear signs of this refocusing (although we are not done).

In doubt, I recommend joining our public discord server (https://discord.com/invite/dagger-io) it is basically a support group for CI/CD nerds who believe that a better way is possible, and want to discuss it with like-minded people.

Thanks for the kind words!

▲

Atotalnoob 2 hours ago | parent [-]

Do you have to use discord? All that information is locked away in a vendors system. Why not choose an open source chat app?

	▲	shykes an hour ago \| parent [-]
		What alternatives would you recommend?

▲

dan_manges 4 hours ago | parent | prev [-]

I've been working on this problem for the past couple of years. State of the art:

- local CLI instead of git push to run

- graph-based task definitions with automatic distributed execution, instead of the job/step abstraction

- automatic content-based caching to skip unnecessary executions (happens a lot in CI pipelines)

- container-based runtime (instead of proprietary base images) without using docker directly (too slow)

There are a lot of other ways to improve the developer experience. Happy to chat with anybody interested, I'm dan@rwx.com