Portable dagger module?

[lapis pecan]

I'm working on a major infra & cicd revamp project with a target to have 'prod-deployable releases' for 5 September 2024. We have a separate github repo that pulls a given semver tagged release from our app source repo, and we run our production delivery workflows with assets from the release. It looks like we'll be waiting some time for v0.12.5 (based on https://github.com/dagger/dagger/milestone/56) - is it possible in v0.12.4 to compile a dagger module and run it elsewhere? I realize that typically the dagger engine resolves the module at the time of dagger call, just looking for some insight before I spend cycles on this aspect.

I imagine the prod delivery workflow can clone the semver tag and pull down the source repo contents and run the dagger module, but that would probably be pretty dangerous and unpredictable even if it did work.

[toxic gyro]

@lapis pecan if I understand correctly, you're asking about having 2 dagger modules - one in the "platform" repo and one in the app repo - and having the platform module load and execute functions from the app module?

[lapis pecan]

Apologies for not following up 🙏 We deliver tenant-dedicated instances of our backend to each of our customers. Our backend mono repo produces releases that are production ready. We have a separate repo that manages delivery to our production environments. Prior to dagger, the prod delivery repo would download the release artifacts from the backend mono repo for a specific semver tag. The most critical release asset is a ready-to-run CLI binary that orchestrates the app delivery lifecycle (pre-deploy, deploy, and post-deploy logics). This CLI is used in development, preprod...everywhere. I've been hard at work daggerizing our development and preprod workflows and am now focused on daggerizing our release and production delivery workflows. We still produce a ready-to-run CLI binary for orchestrating prod app delivery lifecycle, but dagger now builds it and orchestrates the use of it. Consider the dagger call stacks up function in our backend mono repo module, it:

1. is provided an input file/config file
2. builds the underyling CLI that orchestrates our stacks up
3. executes the CLI with the provided input/config file
4. returns stdout

Initially I was thinking about the dagger bits being a portable release asset, but in the time since I made the post, I realized that doesn't make much sense. In the case of the stacks up use case, I think what makes the most sense is a distinct prod delivery dagger module that:

1. is provided the semver tag for the target backend release
2. is provided an input file/config file for the target customer
3. gets the release artifacts/assets from the release
4. executes the CLI with the provided input/config file
5. returns stdout

What do you think?

Rambling on a little more... I've oversimplified it, but we'd enhance the overall dagger workflow to first stacks preview, initiate an approval request (with the preview results) to our prod delivery slack channel, await it, and then either stacks up or exit early.