quick question does attaching a service | Dagger | Page 1

graceful canyon Jun 16, 2023, 8:19 PM

#

@slate lotus so looking at everything after this line?
https://github.com/dagger/examples/blob/main/go/db-service/main.go#L32

slate lotus Jun 16, 2023, 8:19 PM

#

exactly

#

my thought is yes, because the service will be different every time, which would invalidate the cache and produce a new layer, but I might be wrong on that?

graceful canyon Jun 16, 2023, 8:23 PM

#

on multiple runs to same engine I see

#3 service 3R38JMBD501BO
#3 service 3R38JMBD501BO
#3 service 3R38JMBD501BO

fiery blaze Jun 16, 2023, 8:23 PM

#

services are content-addressed, so as long as the service itself didn't change, everything should be cached

#

this is all very carefully implemented for that to be the case 😛

#

the service will be started every time though, because we can't check ahead-of-time whether the client usage will result in a cache hit

graceful canyon Jun 16, 2023, 8:26 PM

#

Does that help @slate lotus ?

slate lotus Jun 16, 2023, 8:27 PM

#

that does! what causes the service to "change"? Anything in the service object that gets returned?

fiery blaze Jun 16, 2023, 8:27 PM

#

Yep - same rules that would normally invalidate a container cache. Different command, different env, different image, etc.

slate lotus Jun 16, 2023, 8:28 PM

#

that helps, thanks!

slate lotus Jun 16, 2023, 9:23 PM

#

One other follow up question, when spawning a service, if I want it to run in the background and keep it alive as long as the dagger session is alive, is there a recommended way to do that? I've used pythons asynchronous context managers to do this in the past like this:


    dockerd_service = with_global_dockerd_service(pipeline.client, settings)

    async with anyio.create_task_group() as task_group:
        task_group.start_soon(dockerd_service.exit_code)
        ctx.dockerd_service = dockerd_service

        # Do your stuff here that requires the service to be alive
        
        # stop the service
        task_group.cancel_scope.cancel()

However, managing the async context around this is tricky when I want to start to manage this across multiple pipelines. The container also shows as failed when I call Cancel on it in the dagger UI. Is there a cleaner way to achieve this? I think I would like to just spawn the service, then it automagically gets shut down after all the other dagger related things I'm doing completes (the async context in which I have the client)

#

(can move this to a help question if it feels like it's more involved)

#quick question does attaching a service