Conversation
Add ./sdk-test, a CLI 1.0 module that black-box tests SDK modules (go-sdk, dang-sdk, typescript-sdk, python-sdk) through a release Dagger CLI, the way a user drives them: dagger -m github.com/dagger/sdk-sdk/sdk-test -W <sdk-repo> check The checks vendor the SDK into a scratch git workspace inside a runner container and exercise the full lifecycle: `dagger sdk install` marks the SDK as-sdk, `dagger module init` scaffolds and registers a module and records the authoring SDK, `dagger generate` succeeds, the generated module serves functions, `dagger sdk module-options` introspects initModule, and `dagger module engine`/`deps` verbs work from the module directory. When run inside this repository the checks redirect to a minimal fixture SDK under .dagger/modules/sdk-test-e2e, keeping the harness self-testing. Verified green against the fixture and dang-sdk on a v1.0.0-beta.7 CLI/engine. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
The root sdk-sdk module now hosts the black-box lifecycle checks that previously lived in ./sdk-test, alongside the function-level contract checks and the Dang SDK helper scaffolding carried forward from the previous root module: dagger -m github.com/dagger/sdk-sdk -W <sdk-repo> check sdk-sdk now fulfills the CLI 1.0 SDK contract itself (targetRuntime, initModule, a @generate hook), so `dagger check` in this repository exercises every check against sdk-sdk as the SDK under test — no fixtures needed. The contract checks were aligned with how the engine actually drives SDKs: initModule is always called with an explicit --path, and the @generate hook is detected via `dagger generate -l` rather than by function name. The root config is now dagger-module.toml (engineVersion v1.0.0-0) with a dagger.toml workspace config, ./polyfill is replaced by the canonical github.com/dagger/polyfill, and the polyfill-e2e and fixture modules are removed. Verified green: 21/21 checks in-repo and 18/18 against a dang-sdk clone on a v1.0.0-beta.7 CLI/engine. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
Run every lifecycle command (sdk install, module init, generate, and the per-check commands) through a single capture wrapper. When a command fails, later commands in the pipeline are skipped and record a marker; their checks then fail with a "prerequisite command failed" message naming the broken stage and its stderr, while the stage's own check reports the actual error. The check report now shows exactly which stage broke and which behaviors were blocked by it, instead of repeating raw nested exec errors. Stage states and their checks now share the same execs, so the pipeline no longer runs install/init twice per pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
Member
|
We should add a part to test client generation, but that should only enabled through a setting because some SDK doesn't support client gen yet. |
Bump the pinned CLI release default to 1.0.0-beta.8 in both sdk-sdk and mod-test ahead of the beta.8 release, and cut mod-test over to the CLI 1.0 command surface: `dagger api call -j` replaces `dagger call -j`, which was removed in beta.7. mod-test was the last piece pinned to a pre-beta.7 CLI for the old verb. The full suite (21/21 checks, including mod-test-e2e and the contract checks that route through mod-test) passes with the new command surface on the beta.7 CLI; runs will fail on the CLI download until beta.8 artifacts are published, at which point no further change is expected beyond re-validating the official SDKs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
Member
|
Do you think you could take care of dagger/dagger#13688 as part of the changes since you remove a lot of the modules? Do we even need that now? |
Contributor
Author
|
New list of functions in the sdk-sdk: |
Add a generate-respects-cwd check encoding the cwd contract from go-sdk's respect_cwd work: generation from inside one module's directory acts on the module cone at or below that directory, so a sibling module elsewhere in the workspace must be left untouched. The harness scaffolds a second module (sibling-mod), commits the scratch workspace as a git baseline, runs `dagger generate` from inside the first module's directory, and asserts via git status that the sibling saw no changes. For SDKs with no-op generation the check passes vacuously; for codegen SDKs it catches cwd-ignoring generate implementations. SdkRun gains workspaceChanges(path) for git-based drift inspection. Verified on a dev main engine (beta.8 preview): 22/22 in-repo, 19/19 against dang-sdk, and 17/18 against go-sdk main — the one failure is a genuine go-sdk finding (a scaffolded module serves no functions after init + generate). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
…scaffolds Bump the pinned CLI default from the unreleased 1.0.0-beta.8 to the released 1.0.0-beta.9, and relax scaffolded-module-serves-functions into scaffolded-module-loads: `dagger api functions` must succeed against a fresh scaffold, but starter templates may expose no functions — go-sdk deliberately scaffolds an empty root type, and "No functions found." on a loadable module satisfies the contract. A broken scaffold (e.g. missing generated bindings) still fails the check at module load. Validated on the released beta.9 CLI and engine: 22/22 in-repo, and 19/19 against the latest main of go-sdk, dang-sdk, typescript-sdk, and python-sdk. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: kpenfound <kyle@dagger.io>
kpenfound
marked this pull request as ready for review
August 4, 2026 17:58
Member
|
Tested on the typescript-sdk repo and it works as expected: |
TomChv
approved these changes
Aug 5, 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
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
Replaces the root
sdk-sdkmodule with the black-box SDK test harness, carrying forward the still-useful tooling from the previous root module. The root module does it all:Lifecycle checks
The checks vendor the SDK module into a scratch git workspace inside a runner container (pinned, checksum-verified release CLI, default
1.0.0-beta.9) and drive it the way a user would:dagger sdk install ./<sdk>succeeds and records theas-sdkmarkerdagger module init <sdk> test-modscaffolds the module, writesdagger-module.toml, installs it indagger.toml, and records the authoring-SDK entrydagger generatesucceeds on the fresh scaffold, and is anchored at the caller's cwd (generate from inside one module's directory leaves a sibling module untouched)dagger api functions— templates may expose no functions yet)dagger sdk module-optionsintrospectsinitModuledagger module engine required/dagger module deps listwork from the module directoryEach lifecycle stage and each contract behavior is its own check; when a stage fails, dependent checks report a
prerequisite command failedmessage naming that stage instead of repeating raw errors.Carried forward from the old root module
initModule+init-template/+helpers/render-init-template/— sdk-sdk is still the SDK for authoring new Dang SDK helper modules (dagger module init sdk-sdk my-sdk)--path,@generatehook detected viadagger generate -lSelf-hosting instead of fixtures
sdk-sdk fulfills its own SDK contract (
targetRuntime,initModule, a no-op@generate), sodagger checkin this repo runs every check against sdk-sdk itself.Housekeeping
dagger-module.toml(engineVersion v1.0.0-0) plus adagger.tomlworkspace config./polyfilldeleted in favor ofgithub.com/dagger/polyfill;mod-testcut over todagger api call -jVerification (released v1.0.0-beta.9 CLI + engine)
dagger check: 22/22main: 19/19main: 19/19main: 19/19main: 19/19🤖 Generated with Claude Code