#New here, so not sure if this is the

1 messages · Page 1 of 1 (latest)

unique basalt
#

Hey! Welcome! Which CI system are you using? I just did a demo an hour ago showing both approaches (call dagger from each step or one call to rule them all) on Jenkins. We'll have a recording soon if you missed it.

In any case, Dagger does nto replace your CI system (yet) it replaces the YAML file and takes over execution. But things like VCS integration, retries, etc.. all that stuff still lives in whatever CI system you are using.

The main benefit is that your Dagger pipeline becomes portable across any CI system and the majority of the logic on the pipeline goes from a provider-specific DSL to a nice program that you write in a langauge of your choice.

frail knoll
#

@sweet wadi there are a few notes on that topic here: https://docs.dagger.io/adopting#integrating-with-ci

It's by no means exhaustive but I recommend reading that whole page is you're looking for "situational awareness"

Adopting Dagger | Dagger

Once you have completed the quickstart, and learned the basic concepts, it's time to take the next step: adopting Dagger in your project. We call this daggerizing. But how does one daggerize a project, exactly?

sweet wadi
#

Thanks y'all... currently on Jenkins but in the process of potentially moving off of it. This is part of the reason why I'm reevaluating our "abstraction" layer tool, as well (it's not implemented to the point where we can lift/shift it currently). I'll give that doc a read, thank you!

frail knoll
#

most relevant paragraph:

Daggerizing leads to simplifying. It's common to merge several large CI pipelines into a single one that just wraps dagger call. This usually leads to massive simplification of the CI configuration, as complex YAML/Groovy/shell spaghetti is replaced by clean code. Taken to the extreme, this process reduces the entire CI configuration to a single dagger call, with everything else happening inside Dagger. Although this sometimes happens, in practice most projects converge to a middle ground, where the CI configuration shrinks to just enough dagger call invocations to take advantage of proprietary CI features. Usually these features are job scaling, and job visualization. The more dependent you are on these proprietary CI features, the more granularity you will need to keep in your CI configuration.

#

and this one:

Remember that Dagger pipelines are not distributed. Each dagger call will execute a single Dagger pipeline on a single Dagger engine. It's the responsibility of the CI system to dispatch jobs across multiple machines. This means that if a single dagger call pipeline doesn't fit in a single machine, you should split it into smaller dagger call pipelines, and configure your CI to run them separately. This way, you can take advantage of the usual scaling features of your CI.

sweet wadi
#

Dagger does nto replace your CI system (yet)

Is there a roadmap for Dagger? I'd love to understand the approach.