Re:Dagger: Define software delivery workflows and dev enviro...
by esafak on Sunday December 14, 2025 @08:21AM
(#46262830)
No, it's code based CI/CD not a build system.
Re:Dagger: Define software delivery workflows and dev enviro...
by ndrpnt on Sunday December 14, 2025 @08:34AM
(#46262903)
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 enviro...
by esafak on Sunday December 14, 2025 @08:36AM
(#46262914)
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 enviro...
by mxey on Sunday December 14, 2025 @10:15AM
(#46263616)
Dagger uses BuildKit. all your “imperative” code does it assemble a graph that’s gonna be executed by BuildKit in dependency order.
Re:Dagger: Define software delivery workflows and dev enviro...
by Too on Sunday December 14, 2025 @11:12AM
(#46264087)
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 nodes, how would it fare?
Re:Dagger: Define software delivery workflows and dev enviro...
by shykes on Sunday December 14, 2025 @12:39PM
(#46264968)
Dagger is a declarative DAG engine. So, yes, you can do that.
Re:Dagger: Define software delivery workflows and dev enviro...
by mxey on Sunday December 14, 2025 @01:16PM
(#46265346)
There is an overhead per container launched so it would probably not be worth it.
Re:Dagger: Define software delivery workflows and dev enviro...
by esafak on Sunday December 14, 2025 @10:18AM
(#46263640)
Yes, but that does not help you build declaratively in dagger, does it? I would like to see an example of how to do so, if you have one.
Re:Dagger: Define software delivery workflows and dev enviro...
by justincormack on Sunday December 14, 2025 @09:04AM
(#46263044)
Its not as fine grained as bazel/buck. That doesnt necessarily matter.
Re:Dagger: Define software delivery workflows and dev enviro...
by elryry on Sunday December 14, 2025 @08:38AM
(#46262927)
Yeah, it's more like a .NET Aspire
Re:Dagger: Define software delivery workflows and dev enviro...
by lowmagnet on Sunday December 14, 2025 @08:40AM
(#46262933)
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 enviro...
by dilyevsky on Sunday December 14, 2025 @12:45PM
(#46265031)
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 enviro...
by kylegalbraith on Sunday December 14, 2025 @12:52PM
(#46265106)
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.
Without the LLM bits, this is basically like Bazel or buck2, right?