#Is there a better approach? What would

1 messages · Page 1 of 1 (latest)

fathom geyser
#

So again just really feeling things out with the function style here, but in my app ci I have:

  • the main module with functions such as: unit-test, lint, build, serve
  • the backend and frontend modules, which are used by the main module to do the test/lint/build/etc for those specific parts of the project
  • a bunch of daggerverse modules as utilities within the above modules, such as golang, netlify, hugo, etc

So my main module is pretty much only made to be called from the cli, while the other modules are designed to be called from other modules (but can still be used by the cli). With that in mind, the functions in my main module are constructed more like individual cli commands instead of graphql types.

For example
Deploy(ctx context.Context, dir *Directory, flyToken *Secret, netlifyToken *Secret, registryUser string, registryPass *Secret)

=
dagger call -m ./ci deploy --dir "." --fly-token $FLY_TOKEN --netlify-token $NETLIFY_TOKEN

Ci(ctx context.Context, dir *Directory, release Optional[bool], tag Optional[string], infisicalToken Optional[*Secret])

=
dagger call -m ./ci ci --dir "."

#

tl;dr I structure my top level functions more like cli commands

#

leaning heavily on those Optional args

fathom geyser
#

@amber pond did you follow a similar pattern or are you using lots of with-* in your CLI invocations?

amber pond
# fathom geyser <@529485027071754273> did you follow a similar pattern or are you using lots of ...

No, I'm just doing dagger call ci|build|test|lint. My main CI modules are built the same way as you described above.

That being said, I can imagine scenarios where I want certain required arguments to be passed as command arguments to a module called from CLI.

For example: when the input is a directory: dagger call do-something ./src/whatever/ --some optional-arg

But that's a different question.

#

Calling reusable modules from the CLI is a great way to test them, but it seems to me that their primary purpose is rather calling them for project specific CI modules.

amber pond