Live data from Hacker News

Dagger: Define software delivery workflows and dev environments

dagger.io

21–30 of 78 posts

Re: Dagger: Define software delivery workflows and dev environments

#21
post #18
post #11

Earlier quoted context omitted.

Do you have any more details on using Cue with GHA? I've also looked at Dagger and been quite disappointed with it (and their terrible documentation).

When I got started it was much more difficult as you had to do a lot of manual work to get things started, and you really had to believe the promises that CUE offered (which I did...), but nowadays they've made so many steps in the right direction that getting something going is far quicker! Here are a few links to whet your appetite: - https://cue.dev/docs/getting-started-with-github-actions-cue... - https://cue.dev…

Maybe it’s just me, but these sample workflows don’t look less complicated, just another kind of complex? If you’re already heavily using CUE in your project this lateral complexity shift might make sense, but I don’t see why I would start using it…

Re: Dagger: Define software delivery workflows and dev environments

#22
post #10

Dagger was something I looked into two or so years ago before they got consumed by the LLM and AI agent hype, and while the promise of being able to run the exact CI workflows locally seemed excellent, it seemed that there's basically no way be a Dagger user without buying into their Dagger Cloud product. I ended up opting for CUE and GitHub Actions, and I'm glad I did as it made everything much, much simpler.

Can you explain/link to why you can't really use this without their cloud product? I'm not seeing anything at a glance, and this looks useful for a project of mine, but I don't want to be trapped by limitations that I only find out about after putting in weeks of work

Overall I like Dagger conceptually, but I wish they'd start focusing more on API stability and documentation (tbf it's not v1.0). v0.19 broke our Dockerfile builds and I don't feel like figuring out the new syntax atm. Having to commit dev time to the upgrade treadmill to keep CI/CD working was not the dream.

re: the cloud specifically see these GitHub issues:

https://github.com/dagger/dagger/issues/6486

https://github.com/dagger/dagger/issues/8004

Basically if you want consistently fast cached builds it's a PITA and/or not possible without the cloud product, depending on how you set things up. We do run it self-hosted though, YMMV.

Re: Dagger: Define software delivery workflows and dev environments

#23
post #14
post #9

Earlier quoted context omitted.

No, it's code based CI/CD not a build system.

I'd say it's somewhere in between. Sure it's marketed in the CI space, but to me the selling point of Dagger is not so much "write your GitHub workflows/GitLab CI in JavaScript" but "local exec, sandboxing, determinism, and fine-grained (remote) caching for mere mortals". So comparing it to Bazel/Buck2 is reasonable.

Its not as fine grained as bazel/buck. That doesnt necessarily matter.

Re: Dagger: Define software delivery workflows and dev environments

#27

Curious if anyone in the thread has / is using windmill? They don't seem to have jumped for AI hype (yet?)... https://www.windmill.dev/

have used it, and i do like it, but the licensing situation is not great. It open source but its not free software by any means.

Re: Dagger: Define software delivery workflows and dev environments

#28
post #5

This looks interesting but I’m trying to understand it in more layman’s terms. Is it more about providing abstractions for llms to work within to do things?

I've never tried it. My first impression based purely on reading the homepage is it adds complexity to something I can already do with a Dockerfile and bash. What can it do that I can't already do more simply?

Re: Dagger: Define software delivery workflows and dev environments

#29
A lot of the comments here feel like they're disappointed that this is a "Docker with unnecessary LLM crap thrown in" when I think what they're really going for is more "LLM workflows with a higher degree of observability and sanity".

I think a more interesting point of comparison is the Claude Code Github Action, Co-Pilot code reviews, etc.

Re: Dagger: Define software delivery workflows and dev environments

#30

Curious if anyone in the thread has / is using windmill? They don't seem to have jumped for AI hype (yet?)... https://www.windmill.dev/

I've tried it, but there's too much "sorry not in the open-source edition, please buy the entreprise edition" stuff all around, which makes it quite unusable
Post reply on HN