Ensure new Gradle Configuration Cache is supported

[ZakTaccardi]

Check out gradle/gradle#13490

[ben-manes]

PRs are welcome.

It is time for the Gradle team to step up and support this plugin's feature, either natively or by becoming the maintainers. It is a basic dependency management capability that was okay to delegate to the community around Gradle 1.x time frame as a very small core team working as consultants. After 8 years, funding / revenue, and a much larger team, its past time that they should take responsibility.

[ZakTaccardi]

Agreed. Relevant issue is gradle/gradle#13498

[re-thc]

4 problems were found storing the configuration cache, 2 of which seem unique.
- Build file 'build.gradle': read system property 'java.runtime.name'
  See https://docs.gradle.org/6.7-rc-3/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Task ':dependencyUpdates' of type 'com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask': invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/6.7-rc-3/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

Tried configuration cache and got the following error.

[ben-manes]

We recurse the multi-project build to resolve all configuration dependencies. That limitation of the configuration cache means its incompatible with this behavior.

If there was a way to capture the configurations during the init phase then maybe the existing logic would work as expected. I suppose that could use an afterEvaluate to build a multi-map of the project.name => configurations, so that it is fully backwards compatible in the outputs.

The alternative would be to follow the jacoco plugin's approach of adding per-project tasks and a root aggregate task, so that projects are not traversed. That would have the benefit of parallel project resolution, but also be an invasive change.

PRs are welcome if someone wants to try fixing this. Otherwise you might conditionally apply the plugin as its not needed in most builds, e.g. use it only on your CI, a github action, or passing in a project property to enable.

[eygraber]

Not sure if you could use this, but I managed to collect dependencies in a way that works with configuration caching. It's not the most performant (because some of the collection happens outside of the task), but it's not bad - https://gist.github.com/eygraber/482e9942d5812e9efa5ace016aac4197

Also see gradle/gradle#12871

[eygraber]

Some work happening along those lines in another library - mikepenz/AboutLibraries#677

[tprochazka]

I don't understand how this plugin can break compilation cache at all, it runs only on demand, right? So it should do nothing until I call the right task.

[eygraber]

True to some degree (other than creating tasks eagerly), but some of us have very long configuration times (in the order of minutes), and it would be nice to not have to wait for that when running these tasks.

[eygraber]

Gradle 7.4 is introducing a task opt-out for the configuration cache.

Also Gradle 7.5 should have more support for making this plugin compatible with the configuration cache.

[eygraber]

I tested the notCompatibleWithConfigurationCache function in 7.4-rc-2 and it seemed to work!

[ben-manes]

nice! A PR is welcome. 😉

I think we'd need to guard with metaClass.respondsTo to for backwards compatibility, like we do elsewhere.

gradle-versions-plugin/src/main/groovy/com/github/benmanes/gradle/versions/updates/Resolver.groovy

Line 420 in 3a6f716

configuration.metaClass.respondsTo(configuration, "getDependencyConstraints")

[eygraber]

#585

[ben-manes]

Thanks @eygraber! 🙂

[delacrixmorgan]

I'm still facing the same issue.

2 problems were found storing the configuration cache, 1 of which seems unique.
- Task `:dependencyUpdates` of type `com.github.benmanes.gradle.versions.updates.DependencyUpdatesTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/8.0.1/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

Even after bumping to the latest 0.46.0 version, is there something I need to add here?

def isStableDependency = { String version ->
    def stableKeyword = ['FINAL', 'GA'].any { it -> version.toUpperCase().contains(it) }
    def regex = /^[0-9,.v-]+(-r)?$/
    return stableKeyword || version ==~ regex
}

dependencyUpdates {
    notCompatibleWithConfigurationCache()
    // Reject non-stable releases if the current used version is stable
    // E.g. if we use "xxx:2.0.0" do not show updates to "xxx:2.1.0-alpha"
    //      if we use "xxx:2.1.0-alpha1" do show "xxx:2.1.0-alpha2"
    rejectVersionIf {
        !isStableDependency(it.candidate.version) && isStableDependency(it.currentVersion)
    }
}

[ben-manes]

Gradle will display a warning when running the task and disable the configuration cache. This is simply a nag but has little negative impact. Otherwise with the cache enabled then the build would crash when the task was run because it could not handle the incompatibility.

The fix did not make the task compatible to run with the cache, but made it work on a build that enabled it. The optimization won't be available, but the penalty is negligible since the task is not normally run. The invasive changes needed for this incubating feature and minor impact means that disabling it was a simple and acceptable fix.

You can use --quiet (or -q) for to hide this.