This message was deleted.

The provider as you use it is evaluated when saving the CC entry, so if the property changes, the CC entry is correctly not reused.

If you have logic that is truly independent of that value (i.e. cc should be reused) you can create a custom ValueSource; the result of that ValueSource is a CC key (changes to it will invalidate CC), but you are free to do <whatever> inside the ValueSource to determine the return value - external executables, environment/system property access, file access, etc. If that isn’t the case, then, yes, as Vampire noted the correct behaviour is to invalidate CC when inputs change (as, by definition, the configuration has changed).

Or of course, you read the envionment variable at execution time if that is when you need it.

Thanks for the explanation, will try what you both have suggested. Is there any difference in performance between using a value source and a provider?

Marginally in your case. A value source is always evaluated when you run the build to determine whether the value it provides changed and thus the CC entry needs to be discarded. And if th CC entry is discarded, the value source is evaluated a second time during CC entry build-up. The provider is evaluated once when the CC entry is stored and on CC reuse the value is just reused.

alright, thanks for that

in any of the execution points -

doFirst

,

doLast

, or

@Action

on custom tasks - you can simply do

System.getProperty("whatever")

What NPE / where?

please don’t paste screenshots, they are hard to read; instead, paste the formatted error text.

providers.systemProperty

is equivalent, in a doFirst, to

project.providers.systemProperty

- as Vampire noted, you can’t use

project

at execution time.

And strongly consider not to degrade the CC errors persistently

yes, I only do that to generate a full report so it's easier to track and work on fully supporting CC as a team

“easier” here masks the actual problem you are having.

I've just tried using

System.getProperty

but the cache is still not re-used, it's re-calculated

it wouldn’t be recalculated for that reason. Output would show why is was recalculated.

it recalculates when I change the system property value

perhaps you are elsewhere capturing system properties.

it specifies this property and I am certain it's not being used anywhere else

17:15:32: Executing ':server:someTask --configuration-cache -DsomeProperty=someVale --stacktrace'...

Calculating task graph as configuration cache cannot be reused because system property 'someProperty' has changed.
Kotlin DSL property assignment is an incubating feature.
Finished applying the Genesis Settings plugin

> Configure project :server
Applying product details creator plugin to reporting-distribution

> Task :server:someTask

BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed
Configuration cache entry stored.

Maybe you (or some plugin you use) requests all system properties that exist? That would make all system properties CC inputs. To make sure we are not lying, remove the

getProperty

line completely and then try again

and, if not already doing so, use the latest Gradle 8.5 as CC behaviour has evolved. Docs are clear on the behaviour here, which matches our experience:

Build configuration inputs include:

• System properties used during the configuration phase

aah, yes. You, Vampire are nothing short of a genius

No you are not:

Copy code

Kotlin DSL property assignment is an incubating feature.

yup, you're right, where using 8.3