#hello folks, I am still looking at https
1 messages · Page 1 of 1 (latest)
The object it's looking for is defined by the SDK, the engine invokes the module when it's being loaded to ask the SDK for the schema of the module.
If you run dagger -m dev develop on the main branch and look at dev/dagger.gen.go towards the bottom you'll see these lines:
case "":
return dag.Module().
WithDescription("Everything you need to develop the Dagger Engine\nhttps://dagger.io\n").
WithObject(
dag.TypeDef().WithObject("DaggerDev", dagger.TypeDefWithObjectOpts{Description: "A dev environment for the DaggerDev Engine"}).
WithFunction(
dag.Function("WithModCodegen",
dag.TypeDef().WithObject("DaggerDev")).
WithDescription("Enable module auto-codegen when retrieving the dagger source code")).
// ... contd. for the rest of the schema definition
In that case the name is DaggerDev, but in your case it should be AModule.
That's the Go SDK obviously, but the SDKs all follow the same protocol.
So this all gets loaded everytime the engine loads the module, not just cached during dagger init or anything like that
generates the code again on engine side and load it from there
That basically. Even though for the Go SDK this is all included in the codegen, codegen gets re-run every time the module is loaded.
👍 thank you. I see that in logs as well after i enabled debug logging in daggerQuery method:
Directory.withoutFile(path: "dagger.gen.go"): Directory!
multi.go:85: 31 : Directory.withoutFile DONE [0.0s]
multi.go:85: 32 : Container.withExec(args: ["codegen", "--output", "/src", "--module-context-path", "/src", "--module-name", "a-module", "--introspection-json-path", "/schema.json"], experimentalPrivilegedNesting: true): Container!
in integration tests, the codegen binary is freshly compiled as well (sorry for all the questions, I am still familiarizing myself with dagger codebase and workflow)