Make module discovery cwd-aware and resolve dagger-module.toml#8
Open
TomChv wants to merge 5 commits into
Open
Make module discovery cwd-aware and resolve dagger-module.toml#8TomChv wants to merge 5 commits into
TomChv wants to merge 5 commits into
Conversation
24 tasks
TomChv
force-pushed
the
feat/make-module-discovery-cwd-aware
branch
from
July 22, 2026 12:14
a01a0b0 to
fb14696
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Mirror the cwd-aware discovery change already landed in the Go, Python and TypeScript SDKs (dagger/dagger#13688): modules are discovered relative to the client's current directory rather than the whole workspace, and both the CLI 1.0 dagger-module.toml and the legacy dagger.json mark a module root. - Mod.path becomes rootPath (workspace-root-relative, the module's stable identity); a new cwd-relative Mod.path renders listings the way a shell user sees them. - JavaSdk.modules(ws) discovers managed modules through the polyfill's cwd-aware findConfigDirs, intersected with the engine-owned asSDK list, and generateAll now goes through it — so running from a subdirectory acts on the project you're in and the projects beneath it. - Point the polyfill dependency in dagger-module.toml (the effective module config) at github.com/dagger/polyfill@main, which provides findConfigDirs. - Wire the workspace dagger.toml for e2e (register java-sdk as the "java" SDK with fixtures) and add modulesCheck / modulesCwdCheck covering both config formats and cwd scoping. Signed-off-by: Tom Chauveau <tom@dagger.io> Signed-off-by: Vasek - Tom C <tom.chauveau@epitech.eu>
TomChv
force-pushed
the
feat/make-module-discovery-cwd-aware
branch
from
July 22, 2026 13:13
fb14696 to
e279505
Compare
`dagger generate` runs java-sdk:generate-all, which Maven-builds every managed module. The e2e fixtures are config-only discovery stubs, so mark them with the skip-generate marker: modules() still lists them, generate never tries to build them (building a stub with no pom fails, which broke `dagger generate`). Also make packager:generate byte-reproducible by stripping Maven's install-time timestamps from the committed prebuilt repo — the comment lines in _remote.repositories (keeping the ">=" local-install markers) and <lastUpdated> in maven-metadata-local.xml. They re-timestamped on every run and made the generate-check report perpetual drift. Signed-off-by: Tom Chauveau <tom@dagger.io>
CI provisions its engine from the legacy dagger.json (the CI CLI is 0.21.7 and predates dagger-module.toml), and "latest" resolved to the 0.21.7 stable engine — which lacks the cwd-aware APIs (Directory.asWorkspace(cwd:), Workspace.cwd, findConfigDirs). That made modules-check and modules-cwd-check error while the other checks passed. Pin the same v1.0.0-0 floor the root dagger-module.toml and the sibling SDK repos already declare, so CI runs a 1.0 engine. Signed-off-by: Tom Chauveau <tom@dagger.io>
CI eagerly loads workspace modules (session --load-workspace-modules). The dang SDK was managing .dagger/modules/e2e, packager and runtime in addition to ".", double-registering e2e (which is also [modules.e2e]). That left the workspace in a state where currentModule.asSDK inside JavaSdk.modules() failed with "get current workspace: no current workspace: workspace not loaded", erroring modules-check and modules-cwd-check while every other check passed. go-sdk uses byte-identical modules() code, manages only "." under its dang SDK, and passes the same checks in the same CI — match that. Signed-off-by: Tom Chauveau <tom@dagger.io>
On the CI engine, currentModule.asSDK inside JavaSdk.modules() fails with
"get current workspace: no current workspace: workspace not loaded",
erroring modules-check and modules-cwd-check (every other check passes).
Read the managed-module list from the passed workspace instead —
ws.sdk(name: currentModule.name).modules — which never touches the ambient
current workspace. This mirrors the Python SDK, whose discovery check passes
in this same CI.
modules-cwd-check now snapshots the whole workspace (ws.directory("/")) so
the re-anchored workspace keeps its dagger.toml for ws.sdk to read.
Signed-off-by: Tom Chauveau <tom@dagger.io>
kpenfound
approved these changes
Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Ports the cwd-aware module discovery change to the Java SDK, matching the sibling SDK PRs:
Tracking issue: dagger/dagger#13688.
Changes
Mod.path→Mod.rootPath— the workspace-root-relative path is the module's stable identity. A new computedMod.pathis a cwd-relative view (".","sub/mod","..") so listings read the way a shell user sees them.JavaSdk.modules(ws)— new cwd-aware discovery. It goes through the polyfill'sfindConfigDirs(anchored at the client's cwd, not the workspace root) and intersects the result with the engine-ownedcurrentModule.asSDK.moduleslist.generateAllnow goes through it, so running from a subdirectory acts on the project you're in and the projects beneath it.dagger-module.tomlresolution — module roots are discovered by either the CLI 1.0dagger-module.tomlor the legacydagger.json(moduleConfigFilenames).dagger-module.toml(the effective module config, which still pointed at the oldsdk-sdk/polyfill) atgithub.com/dagger/polyfill@main, which providesfindConfigDirs.dagger.toml(it still referenced a Go-based runtime that has since moved to Dang) to register the e2e module and thejavaSDK with its fixtures.Tests
Adds
modulesCheckandmodulesCwdCheckto the e2e module, covering discovery of both config formats, cwd walk-down/find-up scoping, and exclusion of modules this SDK doesn't manage.Verified against a
v1.0.0-beta.7engine:Signed-off-by: Tom Chauveau tom@dagger.io