#Pushing Dagger changes to many repos
fleet apex
Hi @undone parrot , this is a very common situation we've observed in larger teams. There are short-term solutions you can implement today, as @dim atlas mentioned - take advantage of language-native package managers to split into common libraries, etc.
The ideal solution, in our opinion, is to:
-
make your Daggerized CI environment (the full set of pipelines and associated logic) its own application, with a standalone source code directory - either in its own repository, or in a common location in your monorepo. In other words: the environment source code should not be intermixed with the source code of any one app.
-
have Dagger itself make it very easy to load any number of environments from the same common source code, in the context of different apps
You can make that pattern work today, and we are actively working on supporting it in a first-class way, as part of #daggernauts
I would love to get on a call with you to learn more about your use case, and get your thoughts on the solutions you're exploring, if that's OK? Feel free to DM
undone parrot
Ok I like the sounds of that. Having dagger load in the latest dagger code would be very interesting to us.
forest stag
We are doing something similar too. Creating a thin wrapper SDK around dagger that we can share with our developers. On top of that we are also creating a CLI which has the context of our enterprise build patterns and is able to run a full ci/cd pipeline using dagger. Advanced users can use the SDK to customize their pipelines but also if you have a "paved path" pattern you can use the CLI without any pipeline code (with minimal yaml config)
undone parrot
@forest stag thanks for the insight. What CI or Workflow tool do you run Dagger on?
forest stag
Jenkins. Specifically Cloud bees Core which is hosted on EKS.
undone parrot
I see, so you are probably using Docker in Docker to make Dagger work on EKS?