This message was deleted.

The dirs we’re copying over are: • ~/.gradle • <project_dir>/.gradle • all build dirs from our different modules

I know I'm not answering the question but... Wouldn't it be simpler just to rely on the remote BuildCache?

yeah, i guess i was just hoping for ~instant builds like we had before fanning out

IIRC up-to-date depends on file timestamps, nothing can be relocated, ... Even if your CI is capable of having the same environment, I guess it will be fragile. But other than that, if the benefit is good enough, feel free to try it.

i don’t think timestamps are taken into account. locally i’ve cloned our repo fresh, copied in my .gradle and build dirs and it all works great.

I haven't really tried, so I can't help that much, but I always felt remote BuildCache is the safe place to be, and build speeds are acceptable

ok actually i DO have a good reason we can’t rely on remote cache. our build process fetches our graphql manifest if it isn’t present. this will cause our core graphql module to have to rebuild. a ton of modules depend on this graphql module, so we still end up with ~half of our build running again.

Using the remote build cache would be the preferred solution here. Though the task history is stored in

<project>/.gradle

, so I am not sure why Gradle wouldn’t find any task history when you copy that file. Is the project still in the same location in the builds? As for the graphql manifest - I suppose you could copy only the manifest between builds. Also, when the manifest doesn’t change, then the downstream modules also don’t have to rebuild, they can be loaded from the cache.

our issue is that the manifest changes very frequently and we currently have no way to lock a version and ensure we fetch the same one every time. this is something we need to address for sure. unsure why <project>/.gradle isn’t giving us the results we want, but we’ll keep playing with it. thank you for the insights.

our issue is that the manifest changes very frequently and we currently have no way to lock a version and ensure we fetch the same one every time. this is something we need to address for sure.

Like I said, copy the manifest from the seed build to the fanned out build, so it doesn’t have to be downloaded again. Then at least in one pipeline you’d use the same manifest.

yeah, sorry i was saying what our general problem with the gradle cache is atm. should work great for the fanned out workflow case though. thanks again.