#Is it more typical to build CI images as part of a Dagger pipeline, or use pre-baked images?

1 messages · Page 1 of 1 (latest)

storm jacinth
#

I'm sure the answer is "it depends", but curious what the prevailing habit is. In traditional CI contexts, I'll tend always to pre-bake my images that are used in the pipelines to ensure both consistency of the tooling and speed of preparing and executing each step (so it's just a docker pull and no build before I can use the image). In the case of Dagger though, since part of the promise is that you can execute it anywhere, it almost seems as though pre-baking images introduces frailty or extra dependency to the process since in order to invoke Functions using those images, the user will need to have access to wherever they're hosted ahead of time, if they're not public. In typical CI this isn't a problem since I'm always running the pipelines somewhere that does have access pretty much by default, but it could be a headache for end users with their own machines and networks.

In documentation, I see a lot of examples of pulling images and installing software into them before using them. Is this the more typical case with Dagger? What are the community's thoughts about when to pre-bake CI tool images and when to let Dagger build them as part of its pipeline execution?

toxic carbon
#

I'd say there's a starting point, and then there's a trend.

The starting point is whatever amount of pre-baking is easiest for your project. Usually dictated by legacy tooling, team policy, or just your personal habits.

The trend is to bake less and less over time, as you grow more comfortable with the "Dagger way".

toxic carbon
#

Over time you can get rid of a lot of intermediary artifacts, and the complexity involved in pre-building, publishing and storing them.