Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dagger: Define software delivery workflows and dev environments

dagger.io

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Dagger: Define software delivery workflows and dev environments

#11

Post by Xiol »

usrme wrote: 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.

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

Re: Dagger: Define software delivery workflows and dev environments

#12

Post by Kinrany »

usrme wrote: 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.

Same: the promise of defining CI/CD in code is good, but the implementation didn't make sense to me even before the LLM stuff

Re: Dagger: Define software delivery workflows and dev environments

#13

Post by tom1337 »

usrme wrote: 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.

Same - we began the migration to Dagger but then switched to just Docker-In-Docker and custom scripts which run vendor-agnostic

Re: Dagger: Define software delivery workflows and dev environments

#14

Post by ndrpnt »

esafak wrote: post #9
jiehong wrote: post #8

Anybody used it? Without the LLM bits, this is basically like Bazel or buck2, right?

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.

Re: Dagger: Define software delivery workflows and dev environments

#15

Post by esafak »

ndrpnt wrote: post #14
esafak wrote: 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.

I wouldn't because build systems like Bazel are declarative and dagger is imperative. I accidentally created a build system in dagger and saw the difference; the code based way was highly branched, and thus unwieldy. I think you would want to call bazel from dagger to handle the build step.

Re: Dagger: Define software delivery workflows and dev environments

#16

Post by digdugdirk »

usrme wrote: 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

Re: Dagger: Define software delivery workflows and dev environments

#18

Post by usrme »

Xiol wrote: post #11
usrme wrote: 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.

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/docs/drying-up-github-actions-workflows/

- https://cue.dev/docs/spotting-errors-earlier-github-actions-...

Definitely read through the CUE documentation (https://cuelang.org/docs/), watch their YouTube videos (https://www.youtube.com/@cuelang/videos), and join the community Slack channel (https://cuelang.org/community/). I've gotten a lot of help in the Slack from both enthusiastic community members and from the developers themselves whenever I've gotten stuck.

Re: Dagger: Define software delivery workflows and dev environments

#19

Post by lowmagnet »

jiehong wrote: post #8

Anybody used it? Without the LLM bits, this is basically like Bazel or buck2, right?

I use it to do builds in our monorepo. We got onboard before the LLM trash features. The base design is ok but there's things I'd do different today if I knew the build stuff would fade away for the LLM push.

Re: Dagger: Define software delivery workflows and dev environments

#20

Post by lowmagnet »

tajd wrote: 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?

It does a pretty good job of caching and that does help speed up builds. I also run all of my end to end tests from it because I can coordinate secrets and clusters of containers through it.
Post reply on HN