Better way to handle builddevelopment dependencies with Dagger?

[small hawk]

One problem I've faced might be better handled by dagger. Would love to hear your thoughts and how you'd handle this.

I've got pipelines that need Go, syft, mage, goreleaser and more. Let's assume not every tool provides a dockerized tool.

I have some of the setup🔨 automated with mage but it's this tooling setup that's the most prone to failure. It happens before I can even use Go/mage.

Would I be better served to build a docker image in GitHub per repo/org that contains all tooling then dagger invokes this? (Similar to Cloudposse Geodesic). Would you require each tool to be individually dockerized instead?

I'm using aqua-proj right now (such an epic project!) for binary installs and it works well but make environmental issues trickier to troubleshoot in CI.

[late walrus]

Both approaches work (a fat images with all the tools vs a container image for each one). I would go with the latter for the following reasons:

• better to compose the pipeline with small tasks that are focused on one thing, it's easier to maintain and to organize the code

• it will allow you to upgrade each tool separately instead of the fat image every time, that way you will reuse the cache more often and it will be overall faster

• easier to troubleshoot, when a step fails, the surface area to investigate the issue is much smaller

It's the same approach with developing any other application, it's always better to have smaller functions organized in a smaller files that are focused on a simple task. The same applies for containers and dagger pipelines.