#Is it possible to pass a *Container as an arg to dagger call?

1 messages · Page 1 of 1 (latest)

modern turtle
#

Hi,

I've got a dagger func that builds a container image and returns the core *Container type. Does the dagger CLI support passing a *Container as an argument? For instance:

dagger call docker-push <container>

serene depot
#

hm, so you want the cli to be the one that chains these together?

#

unfortunately, i don't think there's a way to do that today

#

you can specify a container image arg in a registry with just something like image:tag

#

and we could definitely add an arg to do an import

#

but there's no chaining functionality in the cli where it's all kept internal

modern turtle
#

No worries, thank you @serene depot. I'll do the chaining in the Go code instead.

serene depot
#

that said, i'm curious about the use case - personally, i've wondered about whether we could do chaining like this in the cli

modern turtle
wheat osprey
modern turtle
static herald
#

I've got a dagger func that builds a container image and returns the core *Container type.

If the original function returns a *Container, you can call publish from there. For example dagger call -m "$DAGGER_GO_MODULE" docker-build --bin bin --platform "linux/amd64" publish --address foo. It might need to be changed around to push your multiarch image though

modern turtle
#

Thank you @static herald. That's an elegant solution when building single-arch images!

static herald
#

Ideally we could have an equally elegant solution for multi-arch... I'll think about it more and see if I come up with anything

lean saddle
#

Just searching around on the same kind of issue, where I create a base img for my GO build, and I thought I could pass this base img around and execute different cmd(s) on it. But its looks like this isn't really how its designed to work? When reviewing this dagger module walkthrough..

https://docs.dagger.io/guides/457482/create-app-ci-module#conclusion

I see the base image being built here but I don't connect how its actually being used/consumed? Is it actually referenced ever again? Does the context keep the last built container img?

Standardize Your Application's CI Functions as a Dagger Module | Da...

Introduction

fresh field
# lean saddle Just searching around on the same kind of issue, where I create a base img for m...

👋 it's being referenced in other function calls. for example:

@object_type
class MyModule:
    @function
    async def test(self, source: dagger.Directory) -> str:
        """Run unit tests"""
        return await (
            dag.node(ctr=self.build_base_image(source))
            .commands()
            .run(["test:unit", "run"])
            .stdout()
        )

    def build_base_image(self, source: dagger.Directory) -> dagger.Container:
        """Build base image"""
        return (
            dag.node(version="21").with_npm().with_source(source).install().container()
        )

you can see that build_base_image is being referenced in test in the dag.node function call

#

in this case since functions are part of the same Dagger module, you can just use self.base() from other functions to retrieve your base image

lean saddle
#

Yeah, I've found those examples. I guess what I'm confused about is it a running active container after it executes? When you return it to next function should it be able to then que in another .WithExec for example or do I need to init it again to spin it back up?

fresh field
lean saddle
fresh field
#

You're basically building a DAG when you do dag.container().from().with_exec().with_exec()..... etc

#

and once you call a method on that object that forces that DAG resolution (this methods in python are the ones that return a Coroutine), that will trigger the DAG resolution

#

so when you do await container.sync() or any other function that returns a Coroutine like mentioned above, that's when everything gets resolved/executing

lean saddle
#

Ok so you have to persist stuff through the caches, mnt folders, etc.. I thought you could just init a container, and run it down a pipeline if you preferred but I see the design intent now. Thanks!

fresh field
lean saddle
#

Just anything you are working on, Artifacts etc

fresh field
#

let me give you a quick example

#

you use python, right @lean saddle ?

#

cc @granite lake we should bring back the lazy evaluation docs from 0.9 when possible 🙏

lean saddle
#

@fresh field Learning Go along with Dagger (hence why I'm probably such a bother) I use Python on the daily so I should be able to follow along.

fresh field
# lean saddle <@336241811179962368> Learning Go along with Dagger (hence why I'm probably such...

here's a basic example:

@object_type
class Test:
    @function
    async def run(self, message: str) -> str:
        return await self.base().with_exec(["figlet", message]).stdout()

    @function
    def base(self) -> dagger.Container:
        return dag.container().from_("alpine").with_exec(["apk", "add", "figlet"])

in this case for example, the base function builds a Container object that it'll be resolved/executed when run is called as it's calling the sync function that needs to be awaited

#

In the case of Go, since there's no Promise or Coroutine equivalent, those functions receive a context.Context

lean saddle
#

Ah, I see

fresh field
#

so when self.base is called nothing gets executed at that time in reality. a Container object gets built but in order for that to execute, you need to call a function that actually uses something from that container. Or else, you can optionally use the sync() call to force it to resolve if you don't need anything and you just want to run it

lean saddle
#

OK, yeah this tracks roughly with what I'm trying to do at least in my head, let me switch over to it here in a few and review the GO code. In the GO's context obj, that's where my base container should waiting for me to reference after its created? I was getting confused if it was actually in there or not. There are a few Container methods at various levels and its hard to know exactly which version I'm looking for. I do appreciate the time @fresh field its very helpful! Understanding the raw flow of how it wants to work seems to be half the battle for me so far. ty

fresh field