This message was deleted.

--refresh-dependencies

refreshes all dependencies, checking if they are up-to-date (the HEAD request you see) and downloading if necessary. You can adjust the cache period for dynamic and changing dependencies via:

configurations.all {
            if (state == Configuration.State.UNRESOLVED) {
                resolutionStrategy {

cacheDynamicVersionsFor(2, TimeUnit.HOURS)

                    // snapshots
                    cacheChangingModulesFor(5, TimeUnit.MINUTES)
                }
            }
        }

Thanks for sharing that. So follow up question: why refreshing artifacts that are by definition immutable? There seems to be an inconsistency (or a misconception from myself).

--refresh-dependencies

documentation refers to "dynamic" and "changing" version, so I'm assuming there is at least a 3rd "fixed/final" version type right? That one should be considered immutable and never try to re-download it, right? like Maven. I'm asking because from the scan I shared,

--refresh-dependencies

is not only targeting "dynamic" and "changing" but also regular ones, like

kotlin-stdlib-1.7.10.jar

. For big builds, this is particually an issue, and we spend

3m

of build time just doing

HEAD

requests 🤔

you should not be using

--refresh-dependencies

as a routine part of a build. It’s for resyncing things when they are out-of-whack - switching repos, mispublished versions, etc. to answer your question -

--refresh-dependencies

checks the metadata and artifacts for everything and only downloads things that have changed in some manner from what is cached.

We are not using

--refresh-dependencies

. I mention that to force the refresh, but this is also happening regularly on builds. So the main question stands? Why Gradle does that? and can it be avoided? It's fare for chaning/dynamic dependencies, but in our case, we don't have any.

i see. if it’s happening regularly that could perhaps be an artifact of the repository configuration - multiple repos without content exclusions can be one cause of this. Or perhaps related to caching of dependencies on ephemeral CI.

The sentence quoted in the original message means that it won't change the result of a successful resolution.

--refresh-dependencies

will still make the requests to verify all dependencies, and re-run the resolution instead of using a cached result.

multiple repos without content exclusions can be one cause of this.

Could the repo itself be the root cause? We do have an internal Artifactory aggregator instance

Or perhaps related to caching of dependencies on ephemeral CI.

Can you elaborate on that? We do have ephemeral CI, but I'm focusing on local builds, not CI builds. This happens on dev machines (and they have not clear their cache)

In addition, the point of

--refresh-dependencies

is described in the docs slightly earlier than where you quoted:

Perhaps a repository was initially misconfigured, or perhaps a "non-changing" module was published incorrectly.

This means that even for a dependency that looks "non-changing",

--refresh-dependencies

must poll the metadata again because the assumption is that some dependencies may have changed anyways, and thus become "changing".

So, let me simplify the question, what could cause a

HEAD

request (but not the later

GET

) to be made for a regular final dependency like

kotlin-stdlib-1.7.10.jar

? (considering the project's repositories were not changed nor the cache was evicted)

Do you have a scan of that happening without

--refresh-dependencies

?

> Or perhaps related to caching of dependencies on ephemeral CI.

On ephermeral CI (each build starts clean), such as GitHub Actions, extra configuration is required to cache dependencies. If that configuration is not correct for the specifics of Gradle it can cause all manner of problems (for GA use gradle-build-action which encapsulates all that). But is sounds like this isn’t your main issue atm.

Do you have a scan of that happening without

--refresh-dependencies

?

I do have one from our Enterprise instance, but I can't share it here. Let me try to use a demo project, by reducing the

cacheDynamicVersionsFor

time