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

Dagger: a new way to build CI/CD pipelines

dagger.io

Post reply on HN
Print view View original

171–180 of 267 posts

Re: Dagger: a new way to build CI/CD pipelines

#171

Post by pid-1 »

malkia wrote: post #169
simulate-me wrote: post #155

Earlier quoted context omitted.

In my personal experience, Windows development is absolutely awful. Nothing about it is ergonomic, and the management of the development environment is just painful. Obviously you don't always have a choice, but creating a nice development experience is clearly not a priority for Microsoft. One really basic example: I was deploying files to a Windows Server box using scp, but my internet connection died midway throug…

I love unix tools (grep, sed, cut, etc.), and while there are some good sub-systems (msys2, cygwin), they might be bit heavey. For that the windows version of busybox - https://frippery.org/busybox/ - and then I make sure my scripts are not using too powerful features of said tools (grep especially), such that the version in busybox works. Great, and also possible to port some of that back to linux (but I mostly use…

I use scoop to install this sort of tool in Windows.

iwr -useb get.scoop.sh | iex # install scoop

scoop install coreutils vim nano [...] # yay

Re: Dagger: a new way to build CI/CD pipelines

#175

Post by charsi »

>.. by composing reusable actions, using an intuitive _declarative language_ and API. Actions can safely be shared and reused thanks to a _complete package management system_ ..

That sounds horrible to me. Yet another abstraction layer and set of tools to do something that should be simple. Shell scripts inherently aren't bad. And I really don't see why they'll need more maintenance than using this new tool.

Re: Dagger: a new way to build CI/CD pipelines

#176

Post by shykes »

zepn wrote: post #163
shykes wrote: post #4

Hi everyone, I'm one of the co-founders of Dagger (and before that founder of Docker). This is a big day for us, it's our first time sharing something new since, you know... Docker. If you have any questions, I'll be happy to answer them here!

Thanks for answering Qs. Does this compete directly with Tekton ( https://tekton.dev/ ), or do you imagine a way the two could interoperate? Why choose Dagger over Tekton to power pipelines?

You can (and people do) run Dagger on top of Tekton, in the same way that you might run a Makefile or shell script on top of Tekton. The benefit is that you are less tied to a particular runtime environment. The same Dagger pipeline can run on Tekton, Jenkins, or your laptop. This makes local debugging and testing in particular much easier.

Re: Dagger: a new way to build CI/CD pipelines

#177

Post by shykes »

chologrande wrote: post #162
shykes wrote: post #13

Earlier quoted context omitted.

Yes :) You can write one last Jenkinsfile that runs Dagger, then do everything inside Dagger. Then you can run the exact same Dagger configuration on another CI system, or on your laptop. All you need is a Docker-compatible runtime (we run everything on buildkit under the hood).

> You can write one last Jenkinsfile that runs Dagger I'm very confused by this sentiment. This approach loses the best of existing CI tooling does it not? Jenkins users lose understanding of what's actually being executed, what stage they're in, and how long it took. It might provide convenience, and the a (great) benefit of running locally the same as in your CI environment, but it seems to me this would make it di…

It can be a “megastep” in jenkins, but it doesn’t have to. It could be one individual step that happens to run on Dagger. Both work equally well.

In the “megastep” approach, it boils down to which tool can provide the most useful information. Jenkins is more mature but Dagger has more information about the DAG. So in some cases developers might actually prefer using Jenkins as a “dumb” runner infrastructure. It depends on the situation.

Re: Dagger: a new way to build CI/CD pipelines

#178

Post by shykes »

______-_-______ wrote: post #164
chologrande wrote: post #162

Earlier quoted context omitted.

> You can write one last Jenkinsfile that runs Dagger I'm very confused by this sentiment. This approach loses the best of existing CI tooling does it not? Jenkins users lose understanding of what's actually being executed, what stage they're in, and how long it took. It might provide convenience, and the a (great) benefit of running locally the same as in your CI environment, but it seems to me this would make it di…

I assume if the jenkins-step failed, you'd click a link to the dagger UI to see which dagger-step failed. Alternatively, never open jenkins at all and instead keep a tab open with the dagger UI.

Yes, that’s right. Especially since you’re probably running the same dagger actions all day long in development, upstream from CI.

Re: Dagger: a new way to build CI/CD pipelines

#179

Post by shykes »

shadycuz wrote: post #173

I really wish you would have stuck with a language that is higher in popularity. Python, JavaScript or such.

We did. Each action can be written in the language of your choice (I personally use bash) then wrapped in a declarative CUE config (typically quite short).

Then you compose declaratively in cue.

Here is an example of a package to deploy to netlify: https://github.com/dagger/dagger/tree/main/pkg/universe.dagg...

Re: Dagger: a new way to build CI/CD pipelines

#180

Post by liammclennan »

throwaway787544 wrote: post #166

We've really jumped the shark with people not understanding the word DevOps, haven't we? When the Docker people don't get it, we should probably give up. Fine. "DevOps" now means " some something development something something servers something something operations". Are you happy now, tech world? You've made Patrick Debois cry.

I gave up when a friend defined DevOps as "the entire software development lifecycle". There is a trend of this sort of regression to the mean. Vendors want to jump on a keyword, so they fight to expand the definition to include their thing. Pretty soon everything is "DevOps".
Post reply on HN