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

251–260 of 267 posts

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

#251

Post by ChadyWady »

pjmlp wrote: post #202
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…

Usually it helps by adopting Windows development practices instead of trying to cram UNIX workflows into it. Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?

That's my primary issue with Windows workflows, though. Unless you really convert over to using pretty much only MS tools, it is extremely hard to use them. Meanwhile the "Unix" workflow tends to be a collection of many open source tools with lots of competing solutions.

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

#252

Post by cakoose »

ubercore wrote: post #222
cakoose wrote: post #213

Earlier quoted context omitted.

> What can your team do to reverse this tragedy of the commons? It's tragedies all the way down :-) Making a successful tool in a competitive space is hard enough. Asking a creator to somehow factor in environmental impact isn't going to work. A creator that places additional constraints on themselves will more likely lose out to a competitor that doesn't. This is the kind of thing a carbon tax is perfect for. Cost o…

> Asking a creator to somehow factor in environmental impact isn't going to work. That attitude doesn't leave a great impression for me. I take your points about how difficult it is, but I think we can all do better than throw our hands up in the air. For instance, you could talk about how easy containerization of CI/CD makes it easier to move your pipeline where impact is lowest. Or that you can control your own imp…

> For instance, you could talk about how easy containerization of CI/CD makes it easier to move your pipeline where impact is lowest. Or that you can control your own impact rather than leave it up to the whim of someone like CircleCI.

Oh yeah -- I'm not at all saying Docker is all bad.

* Like you mentioned, increasing interoperability allows the market be more efficient.

* Docker continued the path that VMs started towards making strong isolation even more efficient and accessible.

* Layers and caching are obviously good for resource consumption.

It's just that the original comment seemed to try shaming the Docker creators about what they've built. All they did was try and make something better. And if they didn't, someone else would have.

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

#253

Post by shykes »

solarengineer wrote: post #172

I wonder if there is still opportunity to stop saying “CI/CD”. Here is a talk that I gave last year: https://youtu.be/BJrxYuqG64Q “Why saying ‘CI/CD’ is not enough”

I agree and I think we will get there. I see CI/CD as one of several “micro-categories” that no longer makes sense standalone, and will gradually merge into a single mega-category.

Those include, off the top of my head: continuous integration, continuous deployment , configuration management, infrastructure management, PaaS, IT automation.

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

#254

Post by shykes »

tofflos wrote: post #111

Have you given IDEs any thought? I feel like it isn't write once run anywhere until I can use the same configuration inside the IDE, from the command-line, and in CI. The IDE would need to understand what the dependencies are in order to provide things like auto-completion, debugging and syntax-highlighting.

Yes IDE integration are a great idea and we plan on building those too. What IDE would you personally want to integrate, and what actions would you want it to support?

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

#255

Post by shykes »

shadycuz wrote: post #174

We run most of our CI locally already using vscode devcontainers and precommit. It seems like that is a DIY dagger. Since most of our precommit hooks are just docker containers themselves. I guess dagger does add parallel builds.

Yes, Dagger can be integrated in a devcontainers workflow. How much or how little is done by Dagger is up to you.

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

#256

Post by throwaway787544 »

pnt12 wrote: post #229
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.

Honest question: how would you define it? This question has come up in my team and everyone has a different definition for it.

It has a definition in the same sense that "Agile" and "Lean" and "Six Sigma" have a definition. The definition isn't important, it's the group of ideas that the word refers to.

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

#258

Post by kilburn »

nickysielicki wrote: post #248
maxloh wrote: post #204

Earlier quoted context omitted.

I saw a lot of projects build Windows artifacts with GitHub Actions. It doesn't seem too hard.

Okay, here’s an SDK I use. It’s 16GB. https://docs.microsoft.com/en-us/windows-hardware/drivers/do... Show me how to use this with GitHub actions, if it’s not too hard.

I would use a self-hosted runner for that [1]. You can setup the SDK in that machine and it will be available for any jobs that end up running there.

Depending on your requirements/scale the runner(s) can be a VM in your main machine, a cheapo dedicated server (hetzner/ovh) or even autoscaled hotspot instances in your preferred cloud.

It is less pure than using GH's runners and having an end-to-end setup/teardown for your whole toolchain, but it would work just fine. Definitely better than without any CI.

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

#259

Post by nickysielicki »

kilburn wrote: post #258
nickysielicki wrote: post #248

Earlier quoted context omitted.

Okay, here’s an SDK I use. It’s 16GB. https://docs.microsoft.com/en-us/windows-hardware/drivers/do... Show me how to use this with GitHub actions, if it’s not too hard.

I would use a self-hosted runner for that [1]. You can setup the SDK in that machine and it will be available for any jobs that end up running there. Depending on your requirements/scale the runner(s) can be a VM in your main machine, a cheapo dedicated server (hetzner/ovh) or even autoscaled hotspot instances in your preferred cloud. It is less pure than using GH's runners and having an end-to-end setup/teardown for…

In practice, this is what I’m doing with Jenkins. But my point is that all of these container-first CI solutions lack relevancy for my team.

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

#260

Post by hbogert »

what highly critical comments so far. Every stipulated problem resonates so well for me. I don't really care what the solution is or will be, they are addressing the right problem imo, which is overlooked in the CI/builder space.

So many days are wasted for me because of the ridiculous back and forth to the buildserver when adding or changing automation. My experience is mostly with Gitlab, and I dare to say it's an absolute business strategy for them to lock you in, into the buildserver. They've had the option to use local build runners, but that one lacks fundamental functionality which results in you having to change the Yaml file locally, temporarily, just to extrapolate templates and such. It's horrible. There are so many tickets asking for feature parity for this local-runner and the actual runner on the build server; it's simply ignored or false promises are made. Afaics, Github actions won't do any better.

I do expect Dagger integrates well with Gitlab such that I can download logs, artifacts and such from the Gitlab UI. But I'm afraid if something like Dagger catches on, the existing CI platforms will gatekeep functionality through pure yaml instead of allowing API calls from your pipeline. That would mean something like dagger will have to rely on compiling to a backend language, probably YAML. However, when did the 'one-ring-to-rule-them-all' approach ever work?

So, basically my question is, what's the incentive for the current CI providers to play nicely? And isn't it trying to follow multiple moving targets?

Post reply on HN