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

131–140 of 267 posts

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

#131

Post by jaaron »

nickysielicki wrote: post #44

I’m highly jealous of teams that can containerize all their build tools. If you deal with proprietary toolchains that are tens of gigabytes (Windows WDK, Xilinx Vivado/Vitis) it’s just untenable, and that’s before even mentioning licensing. Even Azure doesn’t have a great solution for WDK development. It’s hard to feel like we’re not being left behind. Bind mounting the tools into the container is an option but at th…

100% this.

I feel like there's a ton of innovation in the cloud/container CI/CD space, but next to nothing elsewhere. In fact, some of the innovations in CI/CD make things _more_ difficult for those of us developing in other environments (such as game development).

There's a lot of low hanging fruit for improving things elsewhere.

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

#132

Post by zamalek »

411111111111111 wrote: post #126
pc86 wrote: post #125

Earlier quoted context omitted.

Are you me? I just started a new job a few weeks ago, and guess what, I'm the first one (in my small group of ~5 or so) to have an M1. First it was just figuring out what the issue was, then trying UTM and manual port forwarding and getting horrible performance, then Colima which seems passable, but the default 2GB of RAM is useless for anything like kafka, so I end up having to allocate half the RAM of my machine ju…

I find it hilarious that you're both seemingly blame docker for these issues.

The whole M1 thing is definitely Apple's fault, but it did lead me to a huge amount of bitrot in Docker tooling.

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

#133

Post by shykes »

EddieRingle wrote: post #116
shykes wrote: post #77

Earlier quoted context omitted.

There will be an optional cloud service (not yet available). Its features will be based on requests from the community. Some problems just can't be solved with a command-line client. For example: visualization of your pipelines; a centralized audit log of all jobs run across all machine; centrally managed access control and policies; etc. We will not rely on unusual licences to restrict competitors from running Dagge…

> We will not rely on unusual licences to restrict competitors from running Dagger as a service. Your "Trademark Guidelines" appear to contradict you: > Third-party products may not use the Marks to suggest compatibility or interoperability with our platform. For example, the claims “xxx is compatible with Dagger”, “xxx can run your Dagger configurations”, are not allowed. > but you have to build your own brand, and…

> > We will not rely on unusual licences to restrict competitors from running Dagger as a service.

> Your "Trademark Guidelines" appear to contradict you:

They do not. Software licenses and trademark guidelines are two different things. Some commercial open-source vendors have changed their licenses to restrict use of the software in various ways - typically to limit competition from large cloud providers. We don't do that, and have no intention to. Our license is OSI-approved and we intend to keep it that way. That is what I am referring to.

> but you have to build your own brand, and you can't confuse and fragment the Dagger developer community itself

This is the intent behind the language in the trademark guideline which you quoted: you can redistribute and modify our code. But if you distribute a modified copy, call it something else.

> > Third-party products may not use the Marks to suggest compatibility or interoperability with our platform. For example, the claims “xxx is compatible with Dagger”, “xxx can run your Dagger configurations”, are not allowed.

> By naming this "Dagger" you're confusing not just your own developer community but the pre-existing one as well.

I disagree. Dagger has existed in private beta for over a year, thousands of engineers have been given access, and I can't remember a single instance of any of them being confused by the name. We have registered the trademark, and nobody has raised an issue.

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

#134

Post by icecap12 »

no_circuit wrote: post #117

During the past few months I wrote a CI/CD pipeline using GitHub actions, Terraform, and Kubernetes. I'm not too sure Dagger would have saved that much time for me unless there was already a fully setup service already being sold. The main issue see so far is that I'd also want bringing up a CI instance of the service the same was as new prod (backup) cluster. All of that is written in Terraform already (and GitHub A…

Glad someone mentioned GH Actions. Recent SaaS issues aside, one of the value-props to me with GH Actions is that I can leverage it in a multi-cloud environment if I'm using GitHub for SCM, which my organization is. There are some other benefits I specifically care about that others might not as well.

Infra is still largely a separate concern (as in, it doesn't matter what I use, I have options). I suppose I need to look into Dagger more to understand the value-prop.

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

#135

Post by vardrop »

shykes wrote: post #57
gregmac wrote: post #54

Your Windows instructions/process needs work. > curl https://dl.dagger.io/dagger/install.ps1 -OutFile install.ps1 This uses the `curl` alias, which is really `Invoke-WebRequest`. It also makes the incorrect assumption I haven't fixed this dumb Microsoft mistake to be an alias to actual curl.exe. > [Windows] We try to move the dagger binary under C:\Windows\System32 Ack, please don't do this! This is similar to instal…

Thank you for the feedback! I referenced it in an issue here: https://github.com/dagger/dagger/issues/1946

EDIT: You can now directly install dagger with scoop by running

  scoop install dagger
I have opened an issue and PR with scoop [0], see also [1]. You can directly install dagger with scoop meanwhile by using

  scoop install https://gist.github.com/vardrop/a25e0c8e2dc055f86a3ff4dd7a7de309/raw/0b7f1e29454d7d2cbe1ae9d6c807ddfcdacb7feb/dagger.json
[0] https://github.com/ScoopInstaller/Main/issues/3460

[1] https://github.com/dagger/dagger/issues/1946#issuecomment-10...

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

#136

Post by pc86 »

411111111111111 wrote: post #126
pc86 wrote: post #125

Earlier quoted context omitted.

Are you me? I just started a new job a few weeks ago, and guess what, I'm the first one (in my small group of ~5 or so) to have an M1. First it was just figuring out what the issue was, then trying UTM and manual port forwarding and getting horrible performance, then Colima which seems passable, but the default 2GB of RAM is useless for anything like kafka, so I end up having to allocate half the RAM of my machine ju…

I find it hilarious that you're both seemingly blame docker for these issues.

I don't blame anyone for the issue. Well, maybe Apple itself but even then blame is pretty harsh. But from someone coming from 12+ years of software development on Windows, with occasional Mac usage personally, to suddenly doing development on a Mac, it was a big shock (mostly in a good way).

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

#137

Post by joseph »

nunez wrote: post #80
Aeolun wrote: post #16

After reading this entire post, I’m still left wondering what problem this solves for me, beyond fluffy promises of ‘everything is going to be better’. At the very least I’d want to see a comparison with what we have now, to show me how this is better. I get that I can try to explore more, but if I don’t get a compelling reason to do so after reading the introductory post, I’m not very motivated to do so Any motivati…

It mostly solves this problem: - write code - run tests - commit code - update CI - commit - CI broken - update CI - commit - CI broken - update CI - ... The workarounds for this are generally awful. For Jenkins, you stage your own instance locally and configure your webhooks to use that. It's exactly as terrible as it sounds, and I never recommend this approach. For Travis and Concourse (I think), you can use their…

My "workaround", if you can call it one, is to design things so they don't need the CI/CD server to get a build/test/deploy feedback loop. I should be able to do any stage of the pipeline without the server, and thus no code is committed until I know it is working. The pipeline is basically a main() function that strings together the things I can already do locally. If I need anything intelligent to happen at any stage of the pipeline, I write a tool to do it using Go or Python or something that I can write tests for and treat as Real Software. After fighting with this for many years, this approach has worked best for me.

I didn't dig deeply into the docs, but Dagger appears to be doing a multi stage pipeline locally. If that is the case, I wouldn't want that either. I use Concourse, which has very good visualizations of the stages, and if I used Dagger there, it would consolidate those stages into one box without much feedback from the UI. Also, with Concourse you can use `fly execute` to run tasks against your code on the actual server, without having to push anything to a repo.

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

#138

Post by taude »

diggs wrote: post #93

There's so much more to CI/CD than the build definitions (e.g. dashboarding, log viewing/retention, access control, manual interventions, secret management, test reporting, etc.) and while some of your points resonate very strongly with me (e.g. local builds), I can't help but wonder what the endgame is here? You've raised $27m to what? Give away a free tool for engineers to define their builds in? While they continu…

I didn't spend a lot of time with the site, but I interpreted Dagger as the Terraform of CICD definitions....

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

#139

Post by shykes »

mountainriver wrote: post #112
speed_spread wrote: post #100

Earlier quoted context omitted.

Full YAML is crazy, but the StrictYAML subset I can definitely live with. I regularly go over the main alternatives (TOML, JSON, XML), and they all have serious warts for config IMO. Better formats exists (such as HOCON) but are much less popular. For a public tool I'd still stick with a YAML subset that everyone knows and can work with a minimum of fuss.

I agree everyone knows YAML but its only really great as a config language, not as a general purpose turing-complete programming language. The answer here is more likely to be something like what Pulumi did

Pulumi is great and we think of it as complementary to Dagger: one is focused on managing infrastructure, the other on deploying applications on top of the infrastructure.

They are more similar in their choice of language than you might think:

* Dagger lets you write actions in any language: Go, Python, Shell, it doesn't matter. Then it runs it in containers, wrapped in a declarative configuration. This allows cross-language interoperability.

* Pulumi also supports existing languages, although it is more deeply integrated, with language-native SDKs (the tradeoff being less supported languages). Eventually they realized that they needed an additional layer to bridge language siloes, otherwise the Pulumi ecosystem is really an archipelago of incompatible components: Pulumi/Go, Pulumi/TS, etc. To solve this Pulumi introduced... a declarative configuration wrapper.

In summary: the best design for this problem requires two layers. One layer for leveraging the existing programming languages with maximum compatibility. And a second to add a declarative configuration model and reduce ecosystem fragmentation. Pulumi and Dagger are both converging on this model, each for their own domain of application.

I personally believe we will see many Dagger + Pulumi integrations in the future :)

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

#140

Post by shykes »

taude wrote: post #138
diggs wrote: post #93

There's so much more to CI/CD than the build definitions (e.g. dashboarding, log viewing/retention, access control, manual interventions, secret management, test reporting, etc.) and while some of your points resonate very strongly with me (e.g. local builds), I can't help but wonder what the endgame is here? You've raised $27m to what? Give away a free tool for engineers to define their builds in? While they continu…

I didn't spend a lot of time with the site, but I interpreted Dagger as the Terraform of CICD definitions....

Yes, that's a reasonable approximation.
Post reply on HN