#Question about calling remote modules:
snow lily
I've logged off for the day else I'd just test this myself, but if any of you happen to know the answer that'd save me the time on Monday!
clear stone
@snow lily module loading is built on top of the regular dagger api. So it has the same caching properties as any other dagger operation
in fact not only does the module loader call the dagger api for eg. fetching git objects, loading local directories etc; it can also be programmed by the dagger api.
That is you can dynamically build your own directory in dagger and load it as a module. Effectively embedding dagger module logic in your own logic as needed
example:
`''
#!/usr/bin/env/dagger
directory |
with-new-file dagger.json '{"name":"foo"}' |
as-module-source |
.help
Clever, but I try to avoid Inception scenarios in my pipelines 😅. So it sounds like fetching a remote module by any means will be subject to caching, so only the first call to any ref will be slow?
clear stone
Clever, but I try to avoid Inception scenarios in my pipelines 😅. So it sounds ...
yes as long as your cache is persisted of course 🙂
if you use dagger cloud to view traces, you can drill down into the module loading, and you'll see the nested git operations and other calls to primitives
clear stone
Clever, but I try to avoid Inception scenarios in my pipelines 😅. So it sounds ...
yeah I wasn't suggesting you use this example for anything serious, it was to demonstrate the neat fact that even module management is programmable in dagger 😛
snow lily
Yeah cache is persistent, just a large nvme drive which is fine for now