Calling functions via code.

[royal grotto]

So, I've got my first Dagger module with a couple of functions (in Go) working. So far so good ( and [I'm actually a lot more excited that I could get this done](#1225839019984683150 message)).

Now, I would like not to call the CLI to run the functions, but rather want to have other code run them. Specifically, I'm looking to run the Dagger function code in a Temporal activity.

The code examples in the old docs cookbook seem to make more sense for this kind of work to me.

So, how to move a new Dagger function to a code executable Dagger function? (and sorry if this is common sense a silly noob question, I'm still learning Go and this "context" bit 🙂 and yeah, I know this is like running a yacht, when I only know how to sail with a dingy. LOL! 😄 )

[rough kettle]

This is a great question, right now it’s not possible but we’re working on it via this issue.

In the meantime the simplest way to get this to work is to write a dagger function using the new way that calls another function.

https://github.com/dagger/dagger/issues/5993

[royal grotto]

Theoretically, the Temporal activity could just run an exec.Command to run the Dagger CLI call command to run the function. But, I'd like to avoid that if I can. 🙂

[royal grotto]

@rough kettle - I put my humble 2 cents in that issue mainly to be updated on any progress, but also to note my use case. Thanks for finding and pointing it out to me.

[hexed copper]

You can execute modules from code you just won’t have the extended generated client (outside of the core API), but you can use a regular GraphQL query. That’s what the CLI does.

[royal grotto]

Unfortunately, what you are saying isn't making sense to me completely. Is there example code I can take a look at that does what you are suggesting @hexed copper ?

[primal ridge]

hey Scott, here's a rough example on how you'd achieve this with the Go SDK

    ctx := context.Background()

    client, err := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))
    if err != nil {
        panic(err)
    }
    client.ModuleSource("github.com/shykes/daggerverse/hello").
        AsModule().Initialize().Serve(ctx)

    res := &graphql.Response{}
    err = client.GraphQLClient().MakeRequest(ctx, &graphql.Request{
        Query: "query{hello{hello}}",
    }, res)

as you can see here, I'm initializing the module via the SDK and then performing a raw graphql call as Helder was mentioning to fetch whatever I need from that module

[royal grotto]

@primal ridge - Thanks. That makes a bit more sense (and I forgot "n't" on "is" above - corrected now), but let's say it's my module locally, or rather my functions. How would I incorporate them? To me, whatever the CLI is doing, I would like to do programmatically, if that possible?

[primal ridge]

the CLI is doing the same thing I posted above. You can also load a module from a relative path in your project and call whatever functions you want the same way

the only caveat is that you won't have "nice" typed objects as Helder was mentioning since you're running all this outside the scope of Dagger

have you thought about changing the approach and having a top level module that triggers your temporal pipelines?

that way you could still keep all the code generation Dagger goodness

so basically:

Top level pipeline Dagger Module > Temporal > Other dagger modules / functions

[royal grotto]

@primal ridge

have you thought about changing the approach and having a top level module that triggers your temporal pipelines?

I don't think that is possible. Temporal would be the actual workflow engine and Dagger is only within the "activity" runner. One of my larger goals is to have an API to receive web-hooks. This API gateway would run a Temporal workflow service. Temporal would then queue the activities defined in the workflow in which Dagger will be called as an activity to do its thing. Activities are their own services.

So, for instance, a repository from our platform gets a PR, this sends the web-hook to the API to start the CI processes. The web-hook app gets the information about the repository in the webhook and runs it's workflow for that repo. The steps in that workflow will be:

1. Platform checks
2. Linting
3. Unit Test
4. e2e Test
5. Vulnerability Test
6. Platform metadata updates to the repo

Being Temporal Activities should be idempotent, as I believe Dagger Functions should be, I'd also say that is a great fit. And, Temporal can do what Dagger can't yet do (without programming around it), and that is to be durable. (correct me if I am wrong). Temporal is my "programming around Dagger".

I could put some or all steps into the same Dagger function/ Temporal activity. I haven't decided on that just yet. 🙂 At first thought, it doesn't seem like it would make sense to have them all ran in one function/ activity though. 🤔