Add support for Gradle configuration cache to Gradle Artifactory plugin

[maxtracking]

AGP 7.x introduced configuration cache: https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:intro
When I tried to enable it in my Android project like this in gradle.properties

org.gradle.unsafe.configuration-cache=true

...I've got the following errors after the simplest ./gradlew help:

* What went wrong:
Configuration cache problems found in this build.

71899 problems were found storing the configuration cache, only the first 4096 were considered, 34 of which seem unique.
- Plugin 'com.jfrog.artifactory': read system property 'awt.toolkit'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'file.encoding'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'ftp.nonProxyHosts'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'gopherProxySet'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'http.nonProxyHosts'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.awt.graphicsenv'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.awt.headless'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.awt.printerjob'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.io.tmpdir'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.runtime.name'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.vendor.url.bug'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.vm.compressedOopsMode'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'java.vm.info'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'jdk.debug'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
- Plugin 'com.jfrog.artifactory': read system property 'kotlin.daemon.jvm.options'
  See https://docs.gradle.org/7.3.2/userguide/configuration_cache.html#config_cache:requirements:undeclared_sys_prop_read
plus 19 more problems. Please see the report for details.

They all seem to be the same standard problem that could be fixed in the plugin thus making it supporting configuration cache (and making builds faster).

For the time being I can workaround it by simply treating these errors as warnings and setting insanely high limit on errors:

org.gradle.unsafe.configuration-cache-problems=warn
org.gradle.unsafe.configuration-cache.max-problems=72000

Ideally JFrog pluging implements all the necessary changes to provide such support.

[NaincyKumariKnoldus]

Hello @maxtracking Can I solve this issue? I can

[maxtracking]

Oh, please go ahead :) All I need is new plugin version that lets me use configuration cache

[Sineaggi]

I believe system properties and environment variables are no longer causing configuration cache failures.

In the current version of gradle (7.4.2) the only configuration cache error is

* What went wrong:
Configuration cache problems found in this build.

1 problem was found storing the configuration cache.
- Plugin class 'org.jfrog.gradle.plugin.artifactory.ArtifactoryPlugin': registration of listener on 'Gradle.addListener' is unsupported
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:build_listeners

Perhaps build listeners will be supported by the configuration cache in the future, or the artifactory plugin could be refactored to not use build listeners.

[doniwinata0309]

Hi any update on this? i stil get error when using configuration cache on jfrog latest version 4.29.4

[joprice]

This would be great to see, as it enables huge performance improvements for large multi-module projects. However, the listener is not the only problem. References to the project from tasks would have to be refactored to use Inputs/providers, tasks cannot reference each other by looking up the instance via the project. This last one is how DeployTask is implemented by finding ArtifactoryTask instances in the build graph. I'm not sure how to get that to play well with the configuration cache.

[ahna92]

Hi ,
Any update on this ,
jfrog is the last plugin left in our project not supporting configuration cache

[jacinpoz]

Hello all,
The configuration cache is now a stable feature since Gradle 8.1 was released in April 2023. This is the last plugin left in our project not supporting configuration cache, it would be great if this issue got solved. Has there been any progress on it?

[yahavi]

@maxtracking @NaincyKumariKnoldus @Sineaggi @doniwinata0309 @joprice @ahna92 & @jacinpoz,
Thanks for using the Gradle Artifactory plugin.
Per your request, we removed the registration of the listener on 'Gradle.addListener'. See jfrog/artifactory-gradle-plugin#49. Version 5.1.0 includes this improvement.

Configuration cache should work now in the following Gradle versions: [7.4.1, 8.2.0). We'll add support for 8.2.0+ in the near future.

We'd appreciate your feedback on that.

[raydenvoldeskine]

I confirm that gradle cache is working now on my project after switching to your version 5.1.0.
However after switching I am blocked with another issue:

I have this sestting in my gradle (fro Android) and this does not work any more:

publishBuildInfo = false

Caused by: groovy.lang.GroovyRuntimeException: Cannot set the value of read-only property 'publishBuildInfo' for object of type org.jfrog.gradle.plugin.artifactory.dsl.PublisherConfig

[yahavi]

I appreciate your input regarding the Gradle cache, @raydenvoldeskine.
Would you be able to open an issue for the exception you encountered? You can do so here: https://github.com/jfrog/artifactory-gradle-plugin/issues/new/choose.

[rpavliuk]

@yahavi Android Studio still complaining about the configuration cache of your plugin version 5.1.0.
Can u recommend a way how to check it using Gradle directly or some other way? I suppose AS can give a false positives on this

[raydenvoldeskine]

Would you be able to open an issue for the exception you encountered? You can do so here: https://github.com/jfrog/artifactory-gradle-plugin/issues/new/choose.

Done: jfrog/artifactory-gradle-plugin#51

Do I assume it right that this is a regression which went through your verification gate? (based on fact that you haven't announced any changes to publishBuildInfo behaviour in your release notes). In this case is creation of a bug "report" through external persons corresponds to your process rules? I have already spent time trying to debug it first and then write a report, the time is billed to my customer.

[yahavi]

@raydenvoldeskine
We fixed the mentioned issue in 5.1.1 by jfrog/artifactory-gradle-plugin#52.
That was an unintended bug introduced in 5.0.0. You can name it regression if you like.

@rpavliuk
Could you please specify the errors you see? Could you check if you still see them in 5.1.1?

Thanks!