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

51–60 of 78 posts

Re: Dagger: Define software delivery workflows and dev environments

#51

Post by shykes »

Too wrote: post #39
mxey wrote: post #31

Earlier quoted context omitted.

Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.

But that dependency order is usually just one big blob of ”COPY src/ . + RUN make”, within that block you have none of the benefits. Bazel/Buck has much finer awareness down to every individual file. Out of curiosity, would it be feasible to take a big cmake project and generate thousands of compile rules into dagger and use it as a substitute for make with sandboxing? I’ve never seen builkit used with such many node…

Dagger is a declarative DAG engine. So, yes, you can do that.

Re: Dagger: Define software delivery workflows and dev environments

#52

Post by dilyevsky »

jiehong wrote: post #8

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

Works fine for us for glueing a bunch of CI steps together which would've been a pile of bash otherwise. Works well with depot.dev caches. We don't use it for anything AI either.

Re: Dagger: Define software delivery workflows and dev environments

#53

Post by shykes »

moltar wrote: post #48

I loved the original promise of Dagger and it’s still 90% great. But one flaw (IMO) that it can’t export artifacts and import into other steps without breaking the cache. Eg if you provide monorepo as input, and then on some step narrow your build to one specific dir, then even when files change outside of that dir then caching still is invalidated. Which makes it extremely verbose and maintenance nightmare to keep m…

You can filter input directories before they are loaded, to avoid this. There's no reason you shouldn't be able to get precise cache invalidation in a large monorepo. If you want, DM me on the Dagger Discord and I'll help you out!

Re: Dagger: Define software delivery workflows and dev environments

#54

Post by kylegalbraith »

dilyevsky wrote: post #52
jiehong wrote: post #8

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

Works fine for us for glueing a bunch of CI steps together which would've been a pile of bash otherwise. Works well with depot.dev caches. We don't use it for anything AI either.

Founder of Depot here! Glad to hear it’s working for you all. Always happy to help expand things or make things better if you ever have ideas.

Re: Dagger: Define software delivery workflows and dev environments

#56

Post by nozzlegear »

sgammon wrote: post #42

Dagger is already a very popular thing -- a DI framework

It's also a type of blade, been around for hundreds of years!

/s I've never heard of Dagger the DI framework but I have heard of this Dagger. Names will overlap sometimes and it's not a big deal.

Re: Dagger: Define software delivery workflows and dev environments

#57

Post by shykes »

digdugdirk wrote: post #16
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

Hi, I'm the founder of Dagger. It's not true that you can't use Dagger without our cloud offering. At the moment our only commercial product is observability for your Dagger pipelines. It's based on standard otel telemetry emitted by our open source engine. It's completely optional.

If you have questions about Dagger, I encourage you to join our Discord server, we will be happy to answer them!

Re: Dagger: Define software delivery workflows and dev environments

#58

Post by mxey »

Too wrote: post #39
mxey wrote: post #31

Earlier quoted context omitted.

Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.

But that dependency order is usually just one big blob of ”COPY src/ . + RUN make”, within that block you have none of the benefits. Bazel/Buck has much finer awareness down to every individual file. Out of curiosity, would it be feasible to take a big cmake project and generate thousands of compile rules into dagger and use it as a substitute for make with sandboxing? I’ve never seen builkit used with such many node…

There is an overhead per container launched so it would probably not be worth it.

Re: Dagger: Define software delivery workflows and dev environments

#60

Post by sontek »

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 examples of your CUE and Github Actions setup?
Post reply on HN