shykes, can you explain or have the folks working on the website explain how is this different or better than just using Jenkins?
Dagger: a new way to build CI/CD pipelines
21–30 of 267 posts
Re: Dagger: a new way to build CI/CD pipelines
#22This seems interesting. But, I wish there was some code to show me what makes it so radically different. It seems like this is targeting developers (or is it devops team?) and I'm excited about the new language here, but I don't see any examples of code. Code engages both my head and heart. I am reusing a lot of code in my CI jobs. I have an upload script that I reuse. I have a DEB package script that I reuse across…
Another starting point: https://github.com/dagger/dagger/tree/main/ci
Re: Dagger: a new way to build CI/CD pipelines
#23What is the benefit of using a new bespoke syntax vs. running docker containers directly? Drone.io does this very well.
One way or the other, you will have to write a declarative configuration describing which containers to run, and how to interconnect them. Then you'll want to add templating to that configuration, perhaps a schema verification tool, some sort of test scaffolding, etc. Our philosophy is that, if you're going to do all those things, it's better to use a dedicated platform with a complete syntax, API and integrated tools, instead of cobbling it together yourself.
Re: Dagger: a new way to build CI/CD pipelines
#24This bait and switch in the docs when trying to see an example for anything other than Github feels a bit off to me:
> If you would like us to document GitLab next, vote for it here: dagger#1677
If you don’t have an example for a specific tool, just don’t add it to your documentation.
Re: Dagger: a new way to build CI/CD pipelines
#25>Write your pipeline once, run anywhere
Ha, finally. The timeline for a pipeline that I wrote recently looks like this:
1. Write local test/deploy script
2. Promote scripts to hosted CI system
3. Local scripts rot
3. CI system down, need to use local scripts again
4. Re-write scripts to be current
5. Force CI system to use my local scriptsRe: Dagger: a new way to build CI/CD pipelines
#26shykes, can you explain or have the folks working on the website explain how is this different or better than just using Jenkins?
Sure, it's better for 3 reasons:
1. You can use the same pipelines in development and automation. Dagger runs on Jenkins, but it also runs on the developer's laptop. This solves a common problem which is drift between the automation available in dev and CI.
2. You're not stuck with Jenkins. If you want to migrate a Jenkins-native pipeline to another CI, you have to rewrite everything. Dagger on the other hand can run on any major CI. This makes migrations much easier, as well as supporting teams with heterogeneous CI setups (which is quite common in larger organizations).
3. You can debug and test your pipelines locally. In theory this is possible with some CI systems. But in practice, the experience is very different. You can actually iterate on your Dagger configuration like you would on regular code: make a change, run, try again, run again. It's quite fun and addictive.
EDIT: there is a 4th reason, which is that Dagger uses buildkit under the hood (the hidden backend for "docker build"). So every action in the DAG is automatically cached when possible. This means that your pipeline is tuned for optimal caching out of the box: no manual tweaking necessary.
Re: Dagger: a new way to build CI/CD pipelines
#27Hi 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!
Congrats on getting this far with the new venture and good luck. Wishing you all the success in the world!
Re: Dagger: a new way to build CI/CD pipelines
#28After 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…
I run a CI application for Laravel developers (Chipper CI).
It turns out, the gap between "works locally!" and "works in CI!" is not negligible, especially when you're not sure "about all that server stuff".
Getting this working locally with a fast cycle time, and then being able to easily move that into a CI environment of your choice sounds exciting to me.
Furthermore, the majority of our customer support is "I can't reproduce this locally but it's broken in CI". Everyone blames the CI tool, but it's almost never the CI tool - just drift between environments. A way to debug locally is a killer feature.
Is it worth an entire, funded company? I'm not sure, but I'm excited for them to exist!
Re: Dagger: a new way to build CI/CD pipelines
#29So if it is a "devops engineer" why not call them just "ops" if they don't do software engineering?..
Historically the devops name comes from the methodology where "dev" and "ops" teams got merged so there'd be at least 1x dedicated ops person for each team of developers, only focussed on that team's operational needs.
Point was to break out of the Developers versus Operations silos and actually be more productive as a single team.
Back in the silo'd days... the ops teams would just flat out refuse to release any code on a Friday. Which doesn't work if you're twitter. Hence the switch.
A lot of my time as a "devops" engineer is reiterating that I can fix and automate as much as you want me too, but if your developers don't think about the infra the code eventually runs on in prod then your software is just gonna keep breaking --- "but it worked fine on my local machine".
So, while I agree the "Devops Engineer" name is a bit ridiculous, and not in the spirit of the original methodology, half of my job is writing software that tries to help developers not break production and the other half is attempting to change the culture, even slightly, towards "oh, wait, will this run in production?".
Re: Dagger: a new way to build CI/CD pipelines
#30Not to be confused with https://dagger.dev/
When I read the headline, my first thought was dagger dependency injection got a CI/CD feature ... which is ridiculous of course. I think this naming will cause confusion, especially since dagger DI is a large project from google.