WIP: move fixture SDK registration into its own workspace - #17
Draft
TomChv wants to merge 1 commit into
Draft
Conversation
Ports dagger/java-sdk#13: the repository's dagger.toml registered this SDK against the e2e fixture modules and the fixture client, so the real workspace advertised test fixtures as managed. That registration moves to a test-only dagger.toml under the fixtures directory, reached through Fixtures.workspace. Incomplete — pushed for discussion, not for merge. discovery:* passes. generate:* and client:* cannot work as written, because codegen needs the session's client-backed workspace and the fixtures config can only be selected by a synthetic one: - asWorkspace(cwd:) re-runs config detection, so the nested dagger.toml is selected, but the workspace carries no client ID and ModuleSource.generateLocalDependencies (mod.dang:97, added in #12) fails in withWorkspaceClientContext. - Workspace.withWorkdir keeps the client but only clones and sets Cwd, so ConfigFile stays the repository's dagger.toml and currentModule.asSDK(ws) reports the SDK is not installed. Codegen then resolves "typescript" to the builtin SDK rather than this one, which passes for the wrong reason. java-sdk does not hit this: its Mod.generate reads only introspectionSchemaJSON and builds the generated files in its own container, so a synthetic workspace is enough. Unblocking here needs an engine change — withWorkdir re-detecting config, or generateLocalDependencies working on a synthetic workspace. Signed-off-by: Tom Chauveau <tom@dagger.io>
TomChv
changed the title
TomChv
marked this pull request as draft
August 7, 2026 16:21
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
1 participant
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.
Not for merge — pushed for discussion. Rebased onto
de65475.Ports dagger/java-sdk#13. The repository's
dagger.tomlregistered this SDK against the eight e2e fixture modules and the fixture client, so the real workspace advertised test fixtures as managed modules. That registration moves into a test-only.dagger/modules/e2e/fixtures/dagger.toml, reached through a newFixtures.workspacehelper.The nesting works because a workspace root is the git root and
dagger.tomlis only the nearest config found walking up from the cwd — so a nested config selects configuration without moving the root. That is whysource = "../../../.."is relative to the config file while theas-sdkpaths stay repo-root-relative.Where it gets stuck
dagger --x-release=v1.0.0-beta.9 check→ 43/48, with two failure signatures that are the two horns of the same problem. Codegen needs the session's client-backed workspace; the fixtures config can only be selected by a synthetic one. There is no way to get both.asWorkspace(cwd:)restore workspace client context: workspace has no client IDwithWorkdir(path)current module is not installed as an SDK in this workspaceasWorkspace(cwd:)re-runs config detection (DetectInRoot), but the workspace carries no client ID, soModuleSource.generateLocalDependencies— used bymod.dang:97, added in generate: stage local dependency closure before codegen #12 — fails inwithWorkspaceClientContext(core/schema/modulesource.go:3120). This is the 3generate:*failures.Workspace.withWorkdirkeeps the client but only clones and setsCwd(core/schema/workspace.go:1471); it never re-detects, soConfigFilestays the repo'sdagger.toml. That is theclient:generate-all-client-checkfailure, and codegen would then resolve"typescript"to the builtin SDK rather than this one — passing for the wrong reason.generate:skip-generate-checkis a third, unrelated and fixable failure:Mod.hasMarkerpasses a bare relativerootPathtows.findUp, which resolves from the cwd, so markers go undetected anywhere but the root. Left alone here since the rest is blocked.Also worth noting: the 3
client:*checks that still pass now do so through the builtin TypeScript SDK, so they are no longer testing this repo.Why java-sdk does not hit this
Not a language difference — the two SDKs generate differently. java-sdk's
Mod.generate(mod.dang:201) reads onlyintrospectionSchemaJSONoff the module source and builds every generated file in its own Maven container, returning a native changeset. That works fine on a synthetic workspace. This SDK delegates to the engine's codegen plus dependency-closure staging, which re-enters the workspace as its owning client. If java-sdk ever adopts dependency staging, itsgenerateCwdCheckbreaks the same way.What would unblock it
An engine change, either:
Workspace.withWorkdirre-running config detection so a client-backed workspace can move cwd and pick up a nesteddagger.toml; orgenerateLocalDependenciesworking on a synthetic workspace.