Not to be confused with https://dagger.dev/
+1 what a strange choice to deliberately conflict with an existing project
There are only so many words.
Dagger: a new way to build CI/CD pipelines
191–200 of 267 posts
Re: Dagger: a new way to build CI/CD pipelines
#192Re: Dagger: a new way to build CI/CD pipelines
#193I thought that maybe the dependency injection tool was expanding into new areas.. https://dagger.dev/
Re: Dagger: a new way to build CI/CD pipelines
#194We'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.
[deleted]
Re: Dagger: a new way to build CI/CD pipelines
#195Earlier quoted context omitted.
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.
I guess I'm a little confused where the line here...
Where is dagger UI and how does it relate to your CI? I don't see it in docs or cli help. Sounds like Dagger UI in this context (above) is providing little value beyond logging if it's not doing workflow execution.
I ask not to talk down on the product, but because I'm actually quite interested. Local execution, plus containerized execution sounds awesome. Just trying to understand the vision.
Re: Dagger: a new way to build CI/CD pipelines
#196How would Dagger compare to Toast? https://github.com/stepchowfun/toast
Re: Dagger: a new way to build CI/CD pipelines
#197Hi 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!
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 language-specific package managers inside another box. This usually breaks any caching / code sharing that the now containerized packages had, resulting in the bloat. The docker image is portable, yes, but disk and RAM efficiency of the systems people are building are awful. It has been the norm for every little microservice to add a few GB of bloat to the overall software system. A dev writes "RUN pip install pytorch" and you have CICD servers pulling down 2GB of pytorch to build the container, every time the software is built, probably forever. Meanwhile species are going extinct and a lot of people are starting to wonder if it's ethical to work in technology at all.
What can your team do to reverse this tragedy of the commons? Can you come up with some equally ergonomic tool that can migrate the container ecosystem on to something that has a solid foundation with good caching?
Re: Dagger: a new way to build CI/CD pipelines
#198Worst company name I've experienced in years. Absolute embarassment. How do I introduce an app named "Dagger" into my stack without sounding caustic or ignorant to my staff? How do you make a service called this without feeling caustic or ignorant. And you have investors?
Are you serious?
Did you think Mailgun was a good name?
edit: Figures Paul Graham is pimping this trash. Good work Sykes, you found a way to float in rich-man-land for another 5 years. I'll never be there but I'm perfectly content living a normal human life. Try it sometime, it may give you some insight into developer tooling and how to profit off of it.
Re: Dagger: a new way to build CI/CD pipelines
#199Earlier 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…
How is possible to restrict someone from making a factual statement like X is compatible with Y?
Re: Dagger: a new way to build CI/CD pipelines
#200Earlier quoted context omitted.
> Don't let the "docker registry" option confuse you: buildkit cache data isn't the same as docker images, so it doesn't carry the same garbage collection and tag pruning problems. IIRC doesn't buildkit store its cache data as fake layer blobs + manifest? I don't see how it can avoid the garbage collection and tag pruning problems since those are limitations of the registry implementation itself.
You still need to manage the size of your cache, since in theory it can grow infinitely. But it’s a different problem than managing regular Docker images, because there are no named references to worry about: just blobs that may or may not be reused in the future. The penalty for removing the “wrong” blob is a possible cache miss, not a broken image. Dagger currently doesn’t help you remove blobs from your cache, but…
Is there a task runtime stat for a blob pruning task?
This sounds like memoization caching: https://en.wikipedia.org/wiki/Memoization
> In computing, memoization or memoisation is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.
Re: SBOM: Software Bill of Materials, OSV (CloudFuzz), CycloneDX, LinkedData, ld-proofs, sigstore, and software supply chain security: "Podman can transfer container images without a registry" https://news.ycombinator.com/item?id=30681387
Can Dagger cache the (layer/task-merged) SBOM for all of the {CodeMeta, SEON OWL} schema.org/Thing s?