contribution/compass
dagger/dagger

Dagger

27 signals · 26 observation events

Open repository ↗

Automation engine to build, test and ship any codebase. Runs locally, in CI, or directly in the cloud

16.2K stars910 forksGoApache-2.0agentscachingci-cdcontainerscontinuous-deploymentcontinuous-integrationdevopsdockerkeyword: Dagger CI
PROJECT NEWS

Release, roadmap, and discussion

All news →
dagger/dagger

Dagger

Developer Infrastructure
Latest stable

v0.21.8

v0.21.8
  • v0.21.8 - 2026-07-29
  • Changed
  • Changeset diffs are now computed from filesystem metadata instead of full-content comparison, significantly speeding up diff computation for large directories. by @marcosnils in
  • Fixed
  • Dockerfile build layer caching so unrelated build-context changes no longer bust the cache: COPY-ed directories now get a content-based cache identity, re-keying downstream steps only when copied content
Original release notes ↗

Publicly indicated next

  • milestone
    vsometimePublicly indicated100% complete · 0 open
  • milestone
    v1.0.1Publicly indicated0% complete · 1 open
  • milestone
    v1.0.0-beta.8Publicly indicated100% complete · 0 open
  • milestone
    v0.21.9Publicly indicated75% complete · 1 open

Prereleases and milestones indicate public plans; they are not delivery commitments.

Observation trail

  1. changedupdatedAt
  2. discoveredinitial snapshot
  3. discoveredinitial snapshot
  4. discoveredinitial snapshot
  5. discoveredinitial snapshot
  6. changedinitial snapshot
  7. changedinitial snapshot
  8. changedinitial snapshot
  9. changedinitial snapshot
  10. changedinitial snapshot
  11. changedinitial snapshot
  12. changedinitial snapshot
  13. changedinitial snapshot
  14. changedinitial snapshot
  15. changedinitial snapshot
  16. changedinitial snapshot
  17. changedinitial snapshot
  18. changedinitial snapshot
  19. changedinitial snapshot
  20. changedinitial snapshot
  21. changedinitial snapshot
  22. changedinitial snapshot
  23. changedinitial snapshot
  24. changedinitial snapshot
  25. changedinitial snapshot
  26. changedinitial snapshot
27 shown
issue

Python SDK ready for 1.0

Close this when the Python SDK is fully ready for 1.0 | Action | Status | PR | Comment | |---|---|---|---| | Module init | ✅ Done | — | We can initialize a module without problem with latest beta version. | | Client init | Missing | — | — | | Codegen for both | — | — | — | | Good default template | 🚧 | https://github.com/dagger/python-sdk/pull/10 | — | | No

importance 9@shykesopenOriginal evidence ↗
issue

Typescript SDK ready for 1.0

Close this when the TypeScript SDK is fully ready for 1.0 | Action | Status | PR | Comment | |---|---|---|---| | Module init | ✅ Done | — | We can initialize a module without problem with latest beta version. | | Client init | ✅ Done | https://github.com/dagger/typescript-sdk/pull/9 and https://github.com/dagger/dagger/pull/13646 | Codegen is outside the eng

importance 7@shykesopenOriginal evidence ↗
issue

Go SDK is ready for 1.0

Close this when the Go SDK is fully ready for 1.0 - Module init - Client init - Codegen for both - Good default template - SDK has full test coverage

importance 7@shykesopenOriginal evidence ↗
issue

Dang SDK is ready for 1.0

Close this when the Dang SDK is fully ready for 1.0 - Module init - Client init - Codegen for both - Good default template - SDK has full test coverage

importance 7@shykesopenOriginal evidence ↗
issue

Java SDK is ready for 1.0

Close this when the Java SDK is fully ready for 1.0 | Action | Status | PR | Comment | |---|---|---|---| | Module init | ✅ Done | — | We can initialize a module without problem with latest beta version. | | Client init | Missing | — | — | | Codegen for both | — | — | — | | Good default template | ✅ Done | https://github.com/dagger/java-sdk/pull/11 | — | | No

importance 6@shykesopenOriginal evidence ↗
issue

PHP SDK is ready for 1.0

Close this when the PHP SDK is fully ready for 1.0 - Module init - Client init - Codegen for both - Good default template - SDK has full test coverage

importance 6@shykesopenOriginal evidence ↗
issue

v0.x modules are given a v1.0 view

Related to, but not a duplicate of https://github.com/dagger/dagger/issues/13654 When a module is being developed for the 1.0.0-beta but still specifies an engineVersion of v0.x, there are two breaking error paths described below. The module can get into this broken state without the module author being aware because when using the module directly on 1.0.0-b

importance 4@kpenfoundopenOriginal evidence ↗
issue

🐞 dagger module init fails "outside changeset root" when dagger.toml is in a subdirectory (monorepo layout)

### What is the issue? `dagger module init <sdk> <name>` fails when the selected `dagger.toml` lives in a **subdirectory** of the git repo rather than at the git root: ``` Error: sdk module init: failed to call sdk module initModule: workspace path .dagger/modules/hello is outside changeset root common ``` This breaks the common monorepo layout where several

importance 4@eunomieopenOriginal evidence ↗
pull request

feat(workspace): import another workspace's dagger.toml

## What Adds a top-level `import` key to `dagger.toml`: a Git ref to another workspace whose configuration is merged **underneath** the current one. ```toml import = "github.com/acme/dagger-base@v1.2.0" # Only the difference from the base: [modules.go.settings] goVersion = "1.24" ``` A team can publish one base workspace config — shared tool versions, module

importance 2@eunomieopenOriginal evidence ↗
pull request

core: pin latest container and Git releases

## Summary Implement #13464's package-manager-style latest-release lifecycle for Git repositories and container images. For Git: - add `GitRepository.latest` - select the greatest stable semantic-version tag, accepting both `v1.2.3` and `1.2.3` - ignore prerelease tags - fall back to the resolved remote HEAD when no stable release tag exists - load remote me

importance 0@tiborvassOriginal evidence ↗
pull request

feat(schema): require declared Workspace! args on module functions

Follows #13845, which made `currentModule.asSDK`'s workspace argument required. This does the same for module functions. ## Problem Workspace arguments on module functions were published as nullable no matter how they were declared, because the engine injects one when the caller leaves it unset (`core/typedef.go`, plus two spots in `core/schema/module.go`).

importance 0@TomChvopenOriginal evidence ↗
pull request

feat: add experimental detachable sessions with source callback lifecycle

## What this adds A detachable session is an engine session that keeps running after the client that created it disconnects. Ordinary Dagger sessions end when their main client disconnects. This PR adds an explicit opt-in mode where accepted work can continue, a later CLI can find and inspect the session, and the user terminates it explicitly. This is useful

importance 0@sipsmaopenOriginal evidence ↗
pull request

workspace: add native polyfill replacements

`dagger/polyfill` currently fills a few gaps that now belong in the engine. This is the additive half of removing it. Tooling modules such as Pytest and Ruff need to find ordinary project roots on disk. `Workspace.findRoots` expresses that policy directly: find roots below the current directory, plus the nearest root above it. `glob` remains available when c

importance 0@grouvilleopenOriginal evidence ↗
pull request

workspace: make changes cwd-relative and isolate SDK generation

This completes the engine side of removing `dagger/polyfill`. `Workspace.changes()` now has one path contract: after the beta.10 cutover, paths are relative to the workspace cwd. This is true for every workspace, forked or not. Code that intentionally edits the repository root can make that explicit with `workspace.withWorkdir(".")`. `Workspace.fork()` only

importance 0@grouvilleopenOriginal evidence ↗
pull request

[backport-0.21] fix(engine): decouple active-clients API from session lifecycle locks

## Summary Backport #13542 to the v0.21 maintenance line for v0.21.9. The Cloud keeper polls `engine { clients }` as part of its composite heartbeat. On v0.21, that enumeration can block behind one session lifecycle lock held across initialization or teardown. Because the keeper does not publish until the query returns, one slow session can suppress all keep

importance 0@matipanopenOriginal evidence ↗
pull request

fix(check): report the checks a rollup can't run instead of dropping them silently

A `@check` that takes a required argument is silently dropped from `dagger check`. `dagger functions` lists it, `dagger check -l` doesn't, and nothing is said — a check that never ran looks exactly like a check that passed. Reproduced on `main` with a two-check module (`checks-required-arg`): ``` $ dagger functions needs-arg A @check with a required argument

importance 0@eunomieOriginal evidence ↗
pull request

fix(elixir): update vulnerable runtime dependencies

## Summary - update `go.opentelemetry.io/otel/sdk` to v1.43.0 - update `google.golang.org/grpc` to v1.82.1 with its required transitive dependencies - refresh the Elixir Go runtime module sums These updates fix the current open Dependabot alerts for `sdk/elixir/runtime/go.mod`.

importance 0@matipanopenOriginal evidence ↗
pull request

[backport-0.21] fix(engine): take session teardown off the client shutdown path

## Summary Backports https://github.com/dagger/dagger/pull/13681 to the v0.21 maintenance line for v0.21.9. When the main client's final connection closes, engine-internal session teardown is now scheduled on a background reaper. This keeps the `/shutdown` response from waiting on unbounded cache and resource reclamation, while the client-critical workspace/

importance 0@sipsmaclosedOriginal evidence ↗
pull request

[backport-0.21] fix: hide registry HTTP probe errors

## Summary Backport the scoped telemetry fix that hides normal registry-protocol HTTP probe failures from successful pull and publish progress. Registry HEAD 404s and auth challenges still occur as expected, but they no longer render as scary failed child rows when the enclosing registry operation succeeds. Also backport the shared private-GitLab test fixtur

importance 0@sipsmaclosedOriginal evidence ↗
pull request

[backport-0.21] engine: prune DAGQL cache by metadata size

## Summary Backports the complete metadata-aware DagQL cache-pruning behavior from #13846 to v0.21: - tracks a coarse structural metadata estimate (`3072*results + 512*terms + 768*class slots`) - prunes cold persisted roots toward a metadata target independently of disk usage - protects active-session and engine-lifetime/unpruneable closures - schedules stru

importance 0@sipsmaclosedOriginal evidence ↗
pull request

engine: support manual metadata pruning

## Summary - add absolute `maxEstimatedBytes` and `targetEstimatedBytes` controls to `Engine.localCache.prune`, including generated CLI and SDK surfaces - run configured structural-memory pruning inline with manual `useDefaultPolicy` requests when automatic GC is enabled, and allow explicit structural pruning when automatic GC is disabled - preserve legacy n

importance 0@sipsmaopenOriginal evidence ↗
pull request

dagql: reduce e-graph result-removal contention

## Motivation Removing a result from a wide output equivalence class repeatedly scanned the class's digests and result postings while holding `egraphMu`. Release and metadata-prune work therefore grew superlinearly as the class widened, increasing lock contention for unrelated cache operations. ## Design This change adds three cache-owned derived indexes: -

importance 0@sipsmaopenOriginal evidence ↗
pull request

fix: make `dagger module init` work from a subdirectory workspace

# fix: make `dagger module init` work from a subdirectory workspace Fixes #13889. ## The bug With a `dagger.toml` in a subdirectory of the git repo — the monorepo layout, several projects under one root — `dagger module init` fails outright: ```console $ mkdir repo && cd repo && git init && mkdir common && touch common/dagger.toml $ cd common && dagger sdk i

importance 0@eunomieopenOriginal evidence ↗
pull request

ci: unpin helm from the retired wolfi helm 3.x package

> [!NOTE] > This unblocks CI repo-wide. `main` and every open PR are currently red. Chainguard moved the wolfi `helm` apk package to the 4.x line, so every `helm~3.18.4` constraint fails to resolve: ``` ERROR: unable to select packages: helm-4-4.2.3-r1: breaks: world[helm~3.18.4] ``` That breaks `ci:bootstrap`, `golang:test-all` (via `e2e/helm`), `helm:lint`

importance 0@eunomieclosedOriginal evidence ↗
pull request

fix(setup): anchor migrated as-sdk module paths at the workspace root

## What `dagger.toml` carries two path conventions that only coincide when the config file sits at the workspace root: - `[modules.<name>].source` resolves against the **config directory** (`ResolveModuleEntrySource`). - `[[modules.<sdk>.as-sdk.modules]].path` is **workspace-root-relative**, everywhere it is read: module→SDK ownership (`sdkOwnersByModulePath

importance 0@eunomieopenOriginal evidence ↗
pull request

fix: classify dotted workspace-relative module refs as local

# fix: classify dotted workspace-relative module refs as local ## Problem `dagger api client init <sdk> <client-path> <module-ref>` fails when the module ref is a workspace-root-relative path whose dot segment is not the first one: ```console $ dagger api client init go clients/api common/.dagger/mymod load module source: local path "common/.dagger/mymod" do

importance 0@eunomieopenOriginal evidence ↗