#Chaining patterns with modular add-on functions

1 messages · Page 1 of 1 (latest)

rose ridge
#

So take the following example. How would you create a module that allows this modularity/composability:

  • Configuring a base container that is used in all the functions (arguments: base image, sdk version, source mount) - everything optional, so that it could fall back to use a default container with predefined versions and implicit mounts.
  • Optional add-ons to the base container for some of the functions (additional file mounts/overrides, secrets required for several other functions)
  • The specific arguments for the concrete end-user functions that work on whatever base container (and addons) were configured (e.g. selecting a test target) before.

I'm looking for a setup where the base image, sdk version, source mount, additional file mounts, secrets do not have to be replicated in each of the terminating functions, basically replicating the patterns of native types (e.g. container) that can be chained easily even on the cli. Can something like this be achieved?

dagger call prepare-base --image=customimage:1.2.3 with-config-override --src=./env-specific.yaml run-tests --unit-only

But also falling back to using defaults like

dagger call prepare-base --image=customimage:1.2.3 run-tests --unit-only

or even

dagger call run-tests

My main motivation is to reuse common (intermediate) steps and reduce the number of arguments for a terminating function by pushing them to a previous step.

#

Chaining patterns with modular add-on functions

#

(Similar case from the docs - but somehow missing the real benefits of chaining?!)

Take this example (https://docs.dagger.io/quickstart/publish, box at the bottom) but with a configurable list of packages to be installed in build.

I would like to be able to run dagger call build --packages bash,git,curl publish --address "ttl.sh/bar" instead of having publish calling build without arguments internally.

To me, the provided example of dagger call build publish --address=... doesn't make a lot of sense if the publish function already calls build... Or am I reading these docs wrong?

rose ridge
#

While looking for something different, I stumbled upon the custom types example here and it seems that this could solve the chaining and structuring issue. Using different objects/types/structs could limit the amount of functions exposed on them.

https://docs.dagger.io/api/custom-types

Custom Types | Dagger

A Dagger module can have multiple object types defined. It's important to understand that they are only accessible through chaining, starting from a function in the main object.

gleaming mural