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

41–50 of 78 posts

Re: Dagger: Define software delivery workflows and dev environments

#41

Post by esafak »

stephen wrote: post #40

I thought Dagger had/has a lot of potential to be "AWS-CDK for CI pipelines". I.e. declaratively setup a web of CI / deployment tasks, based on docker, with a code-first DSL, instead of the morass of copy-pasted (and yes orbs) CircleCI yaml files we have strewn about our internals repos. But their DSL for defining your pipelines is ... golang? Like who would pick golang as "a friendly language for setting up configs"…

They have SDKs in many languages, not just Go. I use the python one. And they use code, not a DSL.

Re: Dagger: Define software delivery workflows and dev environments

#43

Post by esafak »

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.

dagger was originally CUE-based, but there was not enough demand so it was dropped. https://dagger.io/blog/ending-cue-support

Re: Dagger: Define software delivery workflows and dev environments

#44

Post by esafak »

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?

Instead of YAML workflows you write code, and there is an analog of the Github Actions Marketplace (the Daggerverse).

Re: Dagger: Define software delivery workflows and dev environments

#45

Post by Too »

If I understand correctly, this is essentially a more composable way to write Dockerfiles? That alone is a very welcome improvement. They would do themselves a big favor if they were more clear on that in their marketing, instead of boasting around the bush with all kinds of other terminology and claims of redefining foundations.

If I already have a Dockerfile that doesn’t need composition, how does this help me vs being a small cosmetic improvement over ”docker build” command line?

Re: Dagger: Define software delivery workflows and dev environments

#46

Post by pxc »

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

dagger was originally CUE-based, but there was not enough demand so it was dropped. https://dagger.io/blog/ending-cue-support

> If you’ve been active in the Dagger community, this news will come as no surprise. Since we released multi-language support, we have seen a steep decline in usage of our original CUE configuration syntax, and have made it clear that feature parity with newer SDKs would not be a priority.

That is, of course, a self-fulfilling prophecy (or, perhaps, a self-inflicted wound). As soon as Dagger's "multi-language support" came out (actually a bit before), the CUE SDK was rendered abandonware. Development only happened on the new backend, and CUE support was never ported over to the new one.

Re: Dagger: Define software delivery workflows and dev environments

#48

Post by moltar »

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 multiple narrow inputs and keep all those paths up to date.

Re: Dagger: Define software delivery workflows and dev environments

#50

Post by shykes »

LeBit wrote: post #24

Wow, the comments are generally negative. That’s sad. I was about to create a POC to present to my team. What else could be used to abstract away your CICD from the launcher (Jenkins, Argo Workflows, GitHub Actions, etc.)?

Hi, I'm the founder of Dagger. I can't speak to the negativity, but if you're looking for a way to make your CI more portable, I recommend joining our Discord and asking our community directly about the pros and cons of using Dagger. Even if you don't end up using it, there are a lot of people there who are passionate about CI and can recommend other alternatives, in a more constructive and pragmatic way than you are getting here.
Post reply on HN