Dagger in a GitLab CI pipeline: assessment
I evaluated Dagger against a monorepo running 2,000 CI jobs a month, separating pipeline changes from the runner, cache, and hardware constraints that remain.
I evaluated Dagger against a monorepo running 2,000 CI jobs a month, separating pipeline changes from the runner, cache, and hardware constraints that remain.
Caching the package manager store treats a symptom. A pull-through proxy registry is the layer where cross-runner dependency caching actually compounds.
A source trace explains why Dagger's BuildKit cache bridge works on 0.20.1, disappears in 0.21, and leaves type=gha with no effect.
A decision guide to persistent engines, host-side cache bridges, registry proxies, and cold execution after Dagger 0.21 removed BuildKit remote export.
The Go rewrite delivers 10x faster type-checking. It also removes the programmatic API that eslint, Dagger, and every framework template type-checker depends on.
Committing a self-contained mise bootstrap, mounting persistent cache volumes in Dagger, and enforcing the lockfile everywhere so mise.toml is the only source of truth for the toolchain.
Dagger modules install in isolation with a generated pnpm-workspace.yml that has no catalog. The project root's workspace file is never read.
Porting my Dagger module to a repo with a uv Python service and pnpm frontends broke the lockfile-first cache trick, because uv builds the project at install time and pnpm does not.
One container, ten checks, local/CI parity, and three bugs that taught me how Dagger works.