#Gitlab's "new" CI/CD components and dagger modules

1 messages · Page 1 of 1 (latest)

naive mesa
#

Does anyone have any experience with that?

Any experience is welcome. We are currently rewriting our pipelines 😉

#

AND what are some good arguments we could use for using dagger against an org that is heavily invested in Gitlab (Gitlab everything!!)

rigid lion
rigid lion
# naive mesa AND what are some good arguments we could use for using dagger against an org th...

A few key arguments:

  1. It's not either or. Dagger can integrate in an existing Gitlab CI configuration. It's up to you where you draw the line.

  2. Dagger pipelines run locally. This eliminates the "push and pray" problem and speeds up pipeline development dramatically. Once the pipeline logic works, you can still run it in a Gitlab "envelope"

  3. Sometimes thing go wrong in CI. In those cases it's better to have a "break glass" option to deploy from a local machine.

  4. Dagger pipelines are written in a familiar programming language for the dev team, so it's easier to get devs to develop and maintain their own pipeline components, and keep it up to date with their toolchain. This can save the central platform/SRE team a lot of time.

  5. Sometimes you have CI siloes. Having the pipeline logic not be tied to a particular CI platform, makes it much easier to bridge these siloes. It seems like your org is pretty homogenous right now. But tomorrow they might acquire a company that has their own CI; or be acquired; or integrate with customers or partners that don't have Gitlab; etc

  6. Dagger caches everything automatically, which typically makes everything faster.

naive mesa
rigid lion
naive mesa
#

Just a follow-up. I got a lot of it to work today! - All in a days work 😉 Gitlab runners and dagger engine running in kubernetes

ancient nimbus
#

That is awesome @naive mesa !