Hi! I've been trying to setup a read only dependency cache (https://docs.gradle.org/current/userguide/dependency_caching.html#sec:shared-readonly-cache). Works great, pretty much 99.9% of our network transfer has been cut, and builds are faster. but not quite as fast as I had hoped. Despite having this cache available, it seems like Gradle still performs HEAD requests for each dependency. I'm assuming this is to verify the validity of the cached dependency (hash, size, whatever)? These add up to quite a bit of time. Would there be a flag I could turn on to disable those requests, fully trusting the local cache (and falling back to the network should it not be there)? --offline is a bit too aggressive for my taste, and would rather have a --offline-but-maybe-sometimes-why-not EDIT: solution: don't try to debug performance issues on the build that runs with --refresh-dependencies.

I think the only other option you have would be to restructure your dependency cache as a maven (or ivy) repository and declare that repository as the first (highest-priority) repository. It could be either a (read-only) directory on a filesystem, or served through HTTP. This way, if some dependency is not found on that repository, the next, regular ones will be tried (but the dependency won't be automatically added to the read-only repo). Deploying an internal caching proxy service to public maven repositories is probably worth considering at this point.

We have one :D those two minutes are just sending HEAD requests to our artifactory that has pretty much everything proxied and cached.

btw the behavior you are describing looks like --refresh-dependencies is enabled on your builds, or maybe your dependencies are marked as changing. Maybe worth investigating as well?

Oh the dumbass. Yep. Since it is the job that seeds dependencies, we do run it with --refresh-dependencies, which explains those hits. This behavior is not happening on regular builds.