#Understanding caching

1 messages · Page 1 of 1 (latest)

peak delta
#

I have a mostly Go monorepo and I'm really struggling with caching. It's either all or nothing. When anything changes in one folder, tests/lints for the rest are invalidated.

I kinda.. don't get the semantics of Dagger objects, I guess? For example,

https://docs.dagger.io/extending/function-caching/#function-inputs-as-cache-keys
When the Dagger engine checks for a cached result of a function call, it looks at all the inputs to the call:

  1. The source code of the module the function is in
  2. The values of the arguments being provided to the function call
  3. The values of the parent object of the function call
    If a previous function call has been made with all of those inputs at the same value, then there is potential for a cache hit. In other words, all those inputs serve as the "cache key".

What is the value of a "Directory"? is it its contents, or some kind of object identity, or..?

I asked Claude "hi please read all caching docs and look at the dagger/dagger github and steal all the best practices from them" and she couldn't figure it out either.

wintry barn
#

@peak delta is there a chance you could share a small repro or some examples on how you're organizing the monorepo Dagger pipeline? Additionally, if could also share a trace where this invalidation happened we might be able to spot what's happning 🙏

peak delta
#

Oh I’m sorry the repo was private temporarily for work reasons

I can try to come up with a minimal repro but I’d still appreciate getting an intuition for caching.. like, I get content-addressed inputs but dagger doesn’t seem to be using content-addressed? I’m not sure

sick hedge
peak delta
#

Ok super I’ll try it out

half nexus
#

any eta on the next release? 🙂 Would love to try it!