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

221–230 of 267 posts

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

#221

Post by maccard »

antihero wrote: post #215
jeremy_k wrote: post #156

Earlier quoted context omitted.

Do you work in game development? I would love to hear a little bit more about your experience. I play and follow Apex Legends and I'm always so curious about how bugs and regressions seem to make it into every one of their patches. As well as tons of new information that gets data-mined. To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch) and they don't have u…

> To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch) This is likely by choice, feature flags have a fair few advantages over feature branches and are generally far less of a pain point long term.

> This is likely by choice

It's likely because of inertia. I don't work for EA, but the majority of games studios use Perforce for source control which has... awful support for branches. They've got streams which are a huge improvement, but still nowhere near as flexible or easy to use as branches in git.

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

#222

Post by ubercore »

cakoose wrote: post #213
drewm1980 wrote: post #197

Earlier quoted context omitted.

The carbon footprint of the cloud has exceeded the footprint of air travel. A move away from monolithic statically compiled binaries to constellations of microservices (usually bloated docker containers) is a significant part of the problem. Docker's explosive growth is partly due to the convenience of the abstraction it provides, abstracting the entire linux userspace, putting even OS-wide package managers and langu…

> 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 impact rather than leave it up to the whim of someone like CircleCI.

There's no silver bullet with environmental impact, which is why we all have to collectively apply whatever wins we can, wherever we can.

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

#223

Post by raghava »

shykes wrote: post #98
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…

Good question. No, we don't intend to replace the CI service. We think of CI as infrastructure, and there are plenty of great infrastructure providers out there. And you are absolutely correct that for Dagger to succeed, it has to remain agnostic to infrastructure providers, which means we cannot build an infrastructure provider business ourselves. If the experience of hosting Dagger becomes so bad that it affects th…

> there is a great opportunity to help businesses manage their software supply chain

Yes, very much. There are so many layers, components, and their intricate relations that goes totally ignored today at least in most places. Because, doing so is insane amounts of work. Only BigCos can afford to have dedicated teams for 's/w supply chain management', considering the cost-parity-with-returns. However, the solution on this end that works for BigCo doesn't necessarily work for SMEs & startups. That gap isn't small, if am right.

> Another product that is often requested is a visual DAG debugger. When a pipeline break, you want to know why, and staring at your CI logs is definitely not the best experience for that. With a web UI, there's a lot we can do there.

Yes. This definitely helps. But more than a viz DAG element, people look for an early-warning of a failure. Most common build-failure reasons (other than failed tests) -> expired creds used somewhere in the pipeline, provisioning failed/time-out, problem at some other dependent module totally outside org's control (some OSS/dep). People seem to be bothered equally about how to squash'em rather than just where to squash. Locating the part where pipeline broke is just half the part. Actionable insights as to how that pipeline can be healed is the hard part. And considering the diversity of the ecosystem, that's gonna be a wild ride.

BTW, are you folks hiring? "DevOps OS for enterprises" seems very very enthralling, esp for an old toolmaker.

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

#224

Post by simulate-me »

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?

What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.

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

#225

Post by deepsun »

DangitBobby wrote: post #191
j2kun wrote: post #70

Earlier quoted context omitted.

+1 what a strange choice to deliberately conflict with an existing project

There are only so many words.

We can limit our word space by e.g. bird names (like they do internally at Twitter), and still haven't used most of them.

There's a funny paradox: ask people to "name 10 white things", and they do it SLOWER than if you make the task harder by asking to "name 10 white things in your fridge".

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

#226

Post by pjmlp »

simulate-me wrote: post #224
pjmlp wrote: post #202

Earlier quoted context omitted.

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?

What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.

A possible alternative.

https://support.apple.com/guide/mac-help/share-mac-files-wit...

https://docs.microsoft.com/en-us/windows-server/remote/remot...

Another alternative,

https://docs.microsoft.com/en-us/powershell/scripting/learn/...

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

#227

Post by simulate-me »

pjmlp wrote: post #226
simulate-me wrote: post #224

Earlier quoted context omitted.

What’s the alternative? I was deploying from a Mac, so connecting to a Unix box is exactly what I was doing.

A possible alternative. https://support.apple.com/guide/mac-help/share-mac-files-wit... https://docs.microsoft.com/en-us/windows-server/remote/remot... Another alternative, https://docs.microsoft.com/en-us/powershell/scripting/learn/...

I was deploying to a fleet of servers. Having every engineer add every server via the macOS sharing UI or using RDP to manually connect to each host doesn’t seem scalable. Maybe remote power shell sessions would work, but I’m not even sure if there is a power shell client for Mac, and it’s also not clear if remote power shell sessions would fix the open file handle issue.

Experienced Windows devs I talked to said they used Packer from Hashicorp to entirely recreate their server image whenever they wanted to deploy. This process takes hours, but that was the best I found.

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

#228

Post by jcon321 »

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?

I use gitlab for ci/cd, a gitlab-runner runs on a windows based system (legacy aka not .net core so can only build with msbuild.exe). Now I have to copy this release to another windows based system. Are you calling me stupid for using scp via openssh? Would like to hear an alternative? Took me like 5 minutes to set openssh up.

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

#229

Post by pnt12 »

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.

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

#230

Post by wseqyrku »

xmlninja wrote: post #84

"A developer’s dream is a devops engineer’s nightmare" Well, the opposite is very much true as well. A devops engineer's dream is usually a developers nightmare.

I think the opposite cannot be true, because developers come physically before operations.

Isn't it actually devops engineers' job to make it so?

Post reply on HN