#[zenith] New `source` field in dagger.js...
1 messages · Page 1 of 1 (latest)
I think this is a dupe of the issue I was mentioning above https://github.com/dagger/dagger/issues/6291
But this only solves the micro / individual service level; I’d love to see how you build a Dagger pipeline to build all the packages in the Dagger monorepo
Right now each SDK has its own GitHub Action, but the Dagger goal would be to run dagger build and it does everything, yeah?
Oh sorry I missed that dup
@cold crow actually sorry I just saw mine was a dupe of yours, I thought you just created that one 😅 that's my bad. I'll take care of combining them into one after this
@grave edge we're still exploring patterns there
@grave edge my guess would be: the monorepo is a top-level package that possibly imports sub-packages
(I'm finishing up a PR to support the secret passing by env: and file: quick, will try to write out an example right after that in few mins)
I don't think we'd want to expose the hierarchy of sub-modules to the user, in the same way that we show the hierarchy of functions in one module. That would be hierarchy overload for the user IMO
Or maybe like go doc does it: sub-modules are listed briefly. Then it's on to the main topic: the contents of the current module (not mixing in the contents of sub-modules)
@quartz dirge @fickle ocean @queen skiff this is exactly the kind of discussion where prioritizing dogfooding modules would help 😛
If we use a protobuf example. When a protobuf changes, at the top level of a repo, it’s shared by many downstream services.
With the old host based orchestration, it was easy to import some Go code and depend on the output of the protobuf compiler
But with the module stuff, this feels like it’s trickier and currently impossible-ish
Not really, you can take the same code and slap it in a module, should work the same
But does that mean my dagger.json gets a new module added which is higher up my repo?
Which can only be a GH url atm
Meaning I’m always building against version-1?
You can import modules as a relative path today
Only in directories below you though, right?
But I was saying: as a first step, you can take your existing client code, and wrap it in a monolithic module
Just to clarify, you mean mount the entire monorepository?
Yes (easily optimized, ie with includes/excludes etc)