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.

▲

esafak 12 hours ago | parent | next [-]

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.

▲

mxey 10 hours ago | parent [-]

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

▲

Too 10 hours ago | parent | next [-]

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?

	▲	shykes 8 hours ago \| parent \| next [-]
		Dagger is a declarative DAG engine. So, yes, you can do that.
	▲	mxey 7 hours ago \| parent \| prev [-]
		There is an overhead per container launched so it would probably not be worth it.

▲

esafak 10 hours ago | parent | prev [-]

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.

▲

justincormack 12 hours ago | parent | prev [-]

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

▲

elryry 12 hours ago | parent | prev [-]

Yeah, it's more like a .NET Aspire