mit einem Klick
dagger-ci
Running CI locally with Dagger
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Menü
Running CI locally with Dagger
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Coding patterns and conventions (package design, types, DI, docs)
Creating a new package in the monorepo
Debugging (source maps, cache, test failures)
DevContainer runtimes, CLI tools, and version parity with Dagger
Installing a package dependency
Linting and formatting (ESLint, Biome, auto-fix)
| name | dagger-ci |
| description | Running CI locally with Dagger |
Dagger docs: dagger.io · Go SDK CI config:
../../../dagger/· GitHub Actions:.github/workflows/test.yml
Running builds and test suites locally is a great start to making sure software works. But "we can't deploy your machine", and can't trust that the tests run locally didn't accidentally rely on unexpected side effects (e.g. a new dependency that didn't make it into version control).
CI workflows fix that (this project uses Github Actions), but then when CI fails it is incredibly hard/slow to debug.
Dagger allows us to run the full CI workflow locally (our Github Actions just point to Dagger) and iterate faster. Now Dagger can be trusted to create a fully reproducible build that is known to work.
Dagger runs the full CI pipeline inside a container for reproducibility. It:
pnpm i)nx run-many -t build (all packages)nx run-many -t test + nx run-many -t coverage-report (test + coverage)nx run @leyman/main:lifecycle (validates lifecycle config is up to date)If Dagger passes, CI passes.
# Full CI simulation (same as GitHub Actions)
dagger-test
# PATH based reference to scripts/commands/dagger-test
# Set up Dagger for development (initializes module dependencies)
dagger-develop
# PATH based reference to scripts/commands/dagger-develop
Tip: Run
test-cifirst — Much faster for iteration. Use Dagger only to confirm the final result before push. Dagger is also much harder to debug directly (but still easier than cloud CI)
dagger login # connect to Dagger Cloud for pipeline visualization and caching
With Dagger Cloud, you get a web UI showing each pipeline step and its logs, which is useful for debugging CI failures.
dagger/
├── test-and-build/ ← main CI module (Go)
│ ├── main.go ← pipeline definition
│ └── dagger.json
└── modules/
├── node/ ← Node.js installation
├── pnpm/ ← PNPM installation
└── debian/ ← base Debian container
| Use | When |
|---|---|
test-only | During development — fast feedback, uses local cache |
dagger-test | Before pushing — confirms full CI will pass |
test-ci | Middle ground — runs full tests + coverage without containerization |
These are set in dagger/test-and-build/main.go. When upgrading, update both the Go source and the dagger.json engine version.
Container fails but Nx passes — likely an environment difference (missing binary, wrong Node version, network issue). Check the Dagger logs carefully for the specific step that failed.
"dagger: command not found" — Dagger CLI must be installed. In the DevContainer it is available automatically.
Slow first run — Dagger downloads and caches container layers on the first run. Subsequent runs use the cache.