jfrog / artifactory-gradle-plugin

JFrog Gradle plugin for Build Info extraction and Artifactory publishing.
Apache License 2.0
20 stars 15 forks source link

Remove usage of System.getProperties() during Gradle configuration phase #106

Open MikhailShamaev-TomTom opened 5 months ago

MikhailShamaev-TomTom commented 5 months ago

Describe the bug

JFrog plugin calls BuildInfoExtractorUtils.mergePropertiesWithSystemAndPropertyFile, which in turn calls props.putAll(System.getProperties()); at Gradle configuration phase when configuration caching is enabled.

This makes every system property a configuration cache input, so if any property changes and the rest of the configuration does not read this value, configuration cache entry will be invalidated anyway.

For example, in certain cases Gradle sets idea.io.use.nio2 property, nothing in the configuration phase reads this value except 'com.jfrog.artifactory' plugin and that means if that property changes, configuration cache is invalidated.

Unfortunately Gradle does change the property idea.io.use.nio2 every time it re-compiles build.gradle.kts, which means that configuration cache is not usable for a second run.

Current behavior

Clip of configuration cache report: image

On first run

$ ./gradlew tasks --configuration-cache
Calculating task graph as configuration cache cannot be reused because file 'build.gradle.kts' has changed.
..

On second run

$ ./gradlew tasks --configuration-cache
Calculating task graph as configuration cache cannot be reused because system property 'idea.io.use.nio2' has changed.
..

Reproduction steps

In a project with jfrog artifactory plugin configured:

Expected behavior

Second run of Gradle command, the Configuration cache entry reused. output is expected.

Artifactory Gradle plugin version

5.2.0

Operating system type and version

Ubuntu 22

JFrog Artifactory version

No response

Gradle version

8.6

MikhailShamaev-TomTom commented 5 months ago

I don't have exact call stack (Gradle doesn't provide it), but from looking into the code, the issue comes from here:

deeptisjfrog commented 3 months ago

As per customer , The evaluation of system properties should be moved from the Gradle configuration phase to the execution phase. This can be accomplished in Gradle if you use a Provider<> and pass it to tasks inputs, instead of evaluating it in the configuration phase by calling Provider.get(). In this case, Gradle will not record that all system properties were an input for the configuration phase. You may consider reading only the properties that you are interested in, not all of them. In this case, only those properties will be treated as an input. By doing so, the issue will be also solved.