From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

obviously I mean it happens with CC enabled when ireusing it

it seems to be because sortedBy transforms it into eager List&lt;File&gt;

with a file directory it would work only if a direct child has changed, not deeper ones?

Directory sais "contents" no idea if recursive, but in this case it works for me, and is the way i fixed it, but... anyway I guerr it's possible to use a `FileTree`and as it doesn't have reproducible order...it might be an issue

(no idea if directory contents have reproducible order or if the normalization ignores order)

Order should be irrelevant for input files

You have relative path sensitivity configued, so the content should be snapshotted by path.
No reason to employ any sorting on your side for the input-hanlding of Gradle I think.

Ok, so I should only order inside the task to traverse the list of files in a reproducible order.

If that is important for the execution of your task, yes

You never know who supplies the input, so it is better to enforce this internally than to rely it comes in sorted

Really my "mistake" was to think that using a filetree as input could make it miss buildcache sometimes as the order is not reproducible

But is the snapshoting doesn't care about the order then everything is easier

Thanks BTW (that I forgot to say it before)

it's not immediately clear to me why the CC would be discarded. This is a task input that is evaluated at _execution time_

I am not talking about a task input, it is a property in my extension

Why should the configuration cache be discarded?
Just having input files changed should not discard the configuration cache.
If you change a source file and rerun the build, the configuration cache should of course be reused and just the changed file recompiled, even if the input file would be on a task.

Then how can I force the configuration cache to be discarded when that file tree has changed?

the project version is changed based on multiple states, so if the repo is clean, and after that, the repo is no longer clean, the version should be changing, but configuration cache is blocking that change

or, for example, the project version uses the last commit hash, if a new commit appears, the project version has to have that new commit hash, the configuration cache is blocking this change too

`ValueSource`?
`providers.fileContents(...).asBytes.get()`?

If you look at the CC HTML report the files must be listed as inputs.
If they are not listed as inputs, changing them will not invalidate the CC.

Looks like my value source is not changing the version with configuration cache

Well, maybe your value source is wrong then? :slightly_smiling_face:
value source is always recalculated whether CC entry is reused or not.
If CC entry is reused and the value source returns a different result, CC entry is discarded and configuration is done, including evaluating your value source a second time.

that is the weird thing, all tests are passing doing similar things, but with configuration cache, it isn't

```val files: List&lt;File&gt; =
    project.file("${rootProject.rootDir}/.git").walkTopDown().toList()
it.parameters.gitDir.from(files)```
Is it not only necessary to set the git dir to the parameters, it has to be used in order to take it in account to discard the configuration cache?

Your file listing is done at configuration time.
So it cannot invalidate the configuration cache.

I don't understand how ValueSource works, the same input has to be passed to a task?

How can I invalidate it based on any change of those files

If the value of the value source changes, the CC is discarded

So, if the value source is changing without the configuration cache with no issues, but it is not changing with configuration cache, that means I am depending entirely on configuration to indicate the value source that has to be changed, is this an chicken egg issue?

by creating a different jgit instance inside of the value source and using it to check if it is clean it is fixed, I would prefer passing the original one, but I think it is not possible due it is not serializable

Create a build service that you register as operation completion listener. It gets notified after each task finished and you can get from the argument whether the task was skipped.

cool thanks, just to follow up with a bit more detail for folks that might also need to figure this out. The `event` parameter in `onFinish` has a `result` which you can then check what type it is to get the `skipMessage`  or check other types

```    override fun onFinish(event: FinishEvent) {
        val result = event.result
        if (result is TaskSkippedResult) {
            println(result.skipMessage)
        }
    }```


before I continue down this rabbit hole, is there anyway to get a `TaskState` or `TaskExecutionOutcome` from `event`  or `event.result` ?

I'm finding myself rewriting that logic, something like
```    fun OperationResult.getMessage(): String =
        when (this) {
            is TaskSkippedResult -&gt; {
                this.skipMessage
            }
            is TaskSuccessResult -&gt; {
                if (this.isUpToDate) {
                    TaskExecutionOutcome.UP_TO_DATE.message!!
                } else if (this.isFromCache) {
                    TaskExecutionOutcome.FROM_CACHE.message!!
                } else "idk"
            }
            else -&gt; "idk"
        }```

Didn't use it too often myself yet, but I think what you do is exactly what you need to do

are you seeing this in your config-cache html file? Also sometimes, I see more errors in a build-scan.

is this an ad-hoc task that has `doFirst` or `doLast` blocks? I think the most likely case is that one of those is capturing the build script reference. but you should provide more details on how the task is created.

It's part of doLast doFirst, I have figured out that with build scan I get more info :slightly_smiling_face:.

```val version = project.version
val staticResourceDirectory = project.fileTree("$buildDir/resources/main/static/")
tasks.processResources.configure {
    inputs.property("projectVersion", version)
    outputs.cacheIf { true }
    doLast {
        staticResourceDirectory.forEach {
            postProcessApiFile(it)
        }
    }
}```


if `postProcessApiFile` is a function defined locally, yes it's forbidden

```val version = project.version
val staticResourceDirectory = project.fileTree("$buildDir/resources/main/static/").asFileTree
tasks.processResources.configure {
    inputs.property("projectVersion", version)
    outputs.cacheIf { true }
    doLast {
        staticResourceDirectory.forEach {
            //postProcessApiFile(it, version as String)
        }
    }
}```


Even this does not work :slightly_smiling_face: .

```staticResourceDirectory```
 is the issue.

It is of type FileTree but it seems to be forbidden, commenting this reference removes the warning

Is this a case in which the plugin causes so many configuration cache problems that you’d like to automatically disable cc whenever the plugin is applied or something else?

Probably same issue I had where using that function plus `warn` is not possible

My guess would have been that it does some other CC incompatible things like registering incompatible listeners and similar.

yes, i tried to hook up an internal plugin and there's a lot of errors that aren't very obvious how to fix..  our internal classes use gson

```2022-06-24 07:27:50 PDT	               &gt; Configuration cache state could not be cached: field 'constructorConstructor' from type 'com.google.gson.Gson': error writing value of type 'com.google.gson.internal.ConstructorConstructor'
2022-06-24 07:27:50 PDT	                  &gt; Configuration cache state could not be cached: field 'accessor' from type 'com.google.gson.internal.ConstructorConstructor': error writing value of type 'com.google.gson.internal.reflect.UnsafeReflectionAccessor'
2022-06-24 07:27:50 PDT	                     &gt; Configuration cache state could not be cached: field 'overrideField' from type 'com.google.gson.internal.reflect.UnsafeReflectionAccessor': error writing value of type 'java.lang.reflect.Field'
2022-06-24 07:27:50 PDT	                        &gt; Configuration cache state could not be cached: field 'root' from type 'java.lang.reflect.Field': error writing value of type 'java.lang.reflect.Field'
2022-06-24 07:27:50 PDT	                           &gt; Configuration cache state could not be cached: field 'overrideFieldAccessor' from type 'java.lang.reflect.Field': error writing value of type 'jdk.internal.reflect.UnsafeBooleanFieldAccessorImpl'
2022-06-24 07:27:50 PDT	                              &gt; Unable to make field protected final java.lang.reflect.Field jdk.internal.reflect.UnsafeFieldAccessorImpl.field accessible: module java.base does not "opens jdk.internal.reflect" to unnamed module @24b175f```

Hard to tell without seeing your code.
The HTML configuration cache report should tell you though where the problems originate from exactly.
It seems you have some state that the cache tries to serialize that is not serializable.

i can share the full snippet in <#C02MMEYC7HA|>

but it's not blocking since this is CI only code.. so i'm trying to work on guarding it

Untitled.txt

Is `com.foo.plugins.gradle.scan.data.SkippedCompilationTask` your task?

Yes, and I've tried marking that as non cachaeble, but the error surfaces from the plugin too

If I read it correctly, that task has a field called `__buildScanExtension__` where you store the `com.gradle.enterprise.gradleplugin.internal.extension.DelegatingBuildScanExtension` instance which is not properly serializable and thus the tasks state cannot be cached.

```private val taskContext: FooTaskContext by lazy { FooTaskContext(project) }```
at the top level in those plugins

```    @get:Internal
    abstract val buildScanExtension: Property&lt;BuildScanExtension&gt;

 ```

&gt; at the top level in those plugins
Having that in the plugin is probably not the problem.
But I guess you inject that into your tasks and if the cache tries to serialize the state of the tasks to the cache, that fails.
&gt; i did mark that as `@get:Internal`
That's for whether it is considered as input or output for up-to-date checks and build output cache key calculation.
It is meaningless for configuration cache.
The configuration cache needs to serialize the complete state of the object, (unless there was some transient setting I don't remember right now), so that it can restore the tasks state from the cache.
This even affects private fields.
How else should the task work when it is restored from cache and no code to set those fields is executed?

i see, maybe instead of passing buildScan to the task, I should access it directly from `project`

for the other area.. i'll take another look.. it doesn't feel too good guard CI code

on second thought, my build with config cache works locally and it goes through the `__buildScanExtension__` code path, so it makes me think that it's more due to the other part inside `FooTaskContext`

&gt; I should access it directly from `project`
At execution time?
That would not be configuration cache safe either.

It is evaluated each time you request its value if you don't cache the calculation, that is by design afaik.

I could suggest you a mitigation, just have to remember in which project I did it

Ah, found it
```inline fun &lt;reified T&gt; cachedProvider(crossinline block: () -&gt; T): Provider&lt;T&gt; =
    objects
        .property&lt;T&gt;()
        .value(provider { block() })
        .apply {
            disallowChanges()
            finalizeValueOnRead()
        }```

I suppose trick is in `finalizeValueOnRead()`?

If with "trick" you mean the caching, yes.

Unfortunately `Provider` does not have that method, thus the detour over an unmodifiable (`disallowChanges()`) `Property`

Relevant parts:

```Caused by: org.gradle.tooling.GradleConnectionException: Could not execute build using connection to Gradle installation 'C:\Users\javie\.gradle\wrapper\dists\gradle-7.4.2-bin\48ivgl02cpt2ed3fh9dbalvx8\gradle-7.4.2'.```
```Caused by: java.lang.UnsupportedOperationException: Cannot convert relative path build\sandbox-isolated\config--install--pre-commits--enabled-configuration-cache-1-2989901686090158626\test-kit-daemon\7.4.2 to an absolute file.```

Curiously I have similar tests with doesn't have this issue (even with longer paths).

I am on Windows, not sure if this happens in other OS

the difference with the rest of tests is in the rest I am not using a custom `withTestKitDir`

I suppose (from the error) you're giving a relative path to `withTestKitDir`? Have you tried with an absolute one?

I haven't tried, but I don't understand why the debug mode works and the normal one no, looks like a bug to me.

Anyway I will change the implementation to use file with absolute paths 

Fixed by setting it to use the absoluteFile :slightly_smiling_face:

ah nice. though I wish gradle would take care of that :slightly_smiling_face:

I switched it to use

```    public interface SerializableFunction&lt;T,R&gt; extends Function&lt;T,R&gt;, Serializable {}```
instead of `Function` but I still see the same error

That is strange, I saw it working just this week…

E.g. such a task seems to work: <https://github.com/gradle/gradle/pull/21099/files#diff-47dd7a977888628e25e910d61889e23ac90911657aa4c0fcac58efcca8517e85R288-R329>

here's the changed task: <https://github.com/breskeby/elasticsearch/blob/improve-cc-test-coverage/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/test/rest/CopyRestTestsTask.java#L59|https://github.com/breskeby/elasticsearch/blob/improve-cc-test-coverage/build-tool[…]/elasticsearch/gradle/internal/test/rest/CopyRestTestsTask.java>

that is the test: <https://github.com/breskeby/elasticsearch/blob/improve-cc-test-coverage/build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/internal/test/rest/RestResourcesPluginFuncTest.groovy#L123-L180|https://github.com/breskeby/elasticsearch/blob/improve-cc-test-coverage/build-tool[…]ch/gradle/internal/test/rest/RestResourcesPluginFuncTest.groovy>


it fails with the error above, once I change the flag here to true <https://github.com/breskeby/elasticsearch/blob/96a2f88137ce6d61db2836c8bd9cfb866d8283ad/build-tools-internal/src/integTest/groovy/org/elasticsearch/gradle/internal/test/rest/RestResourcesPluginFuncTest.groovy#L126|https://github.com/breskeby/elasticsearch/blob/96a2f88137ce6d61db2836c8bd9cfb866d8[…]ch/gradle/internal/test/rest/RestResourcesPluginFuncTest.groovy>

Sorry I don't see in the test where you set the lambda (additionalConfigToFiletree)

I was thinking maybe the issue is that the lambda is using something from project or another object that is not serializable

Not the test sets it, but the task.
First of the last three links:
&gt; private SerializableFunction&lt;FileCollection, FileTree&gt; additionalConfigToFileTree = FileCollection::getAsFileTree;


Yes, I was looking for the usage in the test to see if the issue was that the lambda had a reference to project

the specific thing about that test in that test class compared to the other tests in that test class is that it invokes gradle twice so it actually tries to read the configuration-cache which failed

<@UAJKMRD2Q> In your case, you also need to fix `CopyRestApiTask` and not only `CopyRestTestsTask`, and then it works: <https://ge.gradle.org/s/p3caqd5ey6y4u/tests/overview>

Is updating to Gradle 7.4 an option?
<https://docs.gradle.org/current/release-notes.html#config-cache>

yea that seems to fix it. Thanks! It takes time internally to move to newer Gradle versions as we run build numbers for a week to compare, but I can add a `org.gradle.unsafe.configuration-cache-problems=warn` for now

I just did this, what you want is a `BuildService`

what also worked for me was to set the existing `BuildListener`  using `useLogger`

`gradle.useLogger new BuildFixListener()`

yeah, i said that. my problem is that i just want a callback. i have a few different things that I want to occur once the build is done so i'm hoping it can be generic

```val myBuildService = gradle.sharedServices.registerIfAbsent("my-build-listener", MyBuildService::class.java) { service -&gt;
                service.parameters.onComplete = buildCompleteListener
            }```

`buildCompleteListener` is just a `() -&gt; Unit` variable

oh right, the passing of the lambda is the problem

yeah, i'm hoping to keep this generic because "logger" is just one use we have

Try with a serializable lambda, that might maybe work

Maybe something like `tasks.clean { publications.all { delete(...) } }`?

That still seems to capture the `artifactId` too early

Ah right, of course.
Somehow misread that the marker publication is added too late.
But with `all` you access its value before it gets properly configured. :confused:

The method `MavenPublicationInternal#getMavenProjectIdentity()` would be perfect if it were public

That `MutableMavenProjectIdentity` field is where the group/artifact/version are actually stored

The practical impact here isn't huge (I basically can't delete locally published Gradle plugin markers), but I wanted to make sure there wasn't a clever trick I was overlooking

Maybe there is, I don't know. :slightly_smiling_face:

Didn't have a too close look, but probably don't depend on the extension at execution time but write the properties of the extension to properties on the tasks. The tasks state is what is serialized into and restored out of the configuration cache.

No, we need to make it stable first then we’ll work on enabling by default.

does it change what happens at configuration time? I need to check.

I was trying to debug something during the configuration phase. but because I'd already run that task without the debug flag, configuration was skipped!

Would you expect `org.gradle.debug` to always invalidate the cache?

I think this was just one of those things that was surprising in the moment, but upon reflection (and conversation; thanks!) makes sense. It reminds me of when people complain about `test` not re-running their tests because Gradle has determined there's no reason to

See also <https://gradle-community.slack.com/archives/C013WEPGQF9/p1656635381045479>

Found it <https://github.com/gradle/gradle/issues/19842>

Yes, this issue is marked as one that should be fixed before configuration cache is marked as stable. But I don’t know If `MavenPublication` will be serializable or there will be any other way to solve this

Good point Tony. AFAIK the report doesn't include that information. Care to open an issue?

<https://github.com/gradle/gradle/issues/21290>

<https://docs.gradle.org/7.4.2/release-notes.html>
&gt; Automatic detection of environment variables, system properties and Gradle properties used at configuration time
That should help, unless you're already on 7.4.2

current 7.4.2 and tried 7.5 , but that won't help because the issue is that it's used in configuration time...because mavenPublication requires it to be set in configuration time

<https://gradle-community.slack.com/archives/CDB9Q0MPT/p1658309907626819?thread_ts=1658309907.626819&amp;cid=CDB9Q0MPT|https://gradle-community.slack.com/archives/CDB9Q0MPT/p1658309907626819?thread_ts=1658309907.626819&amp;cid=CDB9Q0MPT>

a function declared like that is in project scope, which means it can't be used with configuration caching. I'm not sure if it's possible to avoid that in the Groovy DSL. try the Kotlin DSL or a binary plugin instead.

wait, so there is no way to declare a function in groovy when using configuration caching? o.O

exposing variables seems to be working when using the ext {} block but I can’t seem to get it work with methods

defining a class - or a proper task subclass - may work

Here it is on the roadmap: <https://github.com/orgs/gradle/projects/31>

That link just took me to the roadmap. This should link to the issue - <https://github.com/gradle/build-tool-roadmap/issues/28>

Sounds like you are using the project at configuration time. That would be ok regarding CC, shouldn't it?

Right, I can try to move that logic at configuration time and provide required data to the task. I will give it a try

I'm setting up the provider:
```val gitVersionProvider = project.providers.of(GitVersionValueSource::class) {}```
inside the apply method of the plugin and access it `gitVersionProvider.get()` from inside the task register.

could you please share a build scan of a failed build or provide a more complete reproducer?

Hm, actually it sounds familiar to me.
Something about the service getting resolved very late and then not being available anymore or something like that.

Unfortunately, I cannot remember where that conversation was and don't find it right now. :disappointed:

Ok, I will work on putting together an example project.

Hey guys, I found the issue.  My project was started with Gradle 7.4.2 and the update to 7.5 didn't work until I deleted all of my .gradle caches.  So the above error is what you will see on 7.4.2  but everything works as expected on 7.5 :thumbsup:

you can't, I've seen this question asked before in this channel, but I can't find it

oof.  that would suck if true.  I tried searching in this channel but must not have hit the right search terms.  I'll try scrolling instead...

i have it enabled by default in our checked in `gradle.properties` and in CI, i'm using `--no-configuration-cache`

it would have been a lot easier if I could do it in a Gradle script

my use case is an internal developer beta program where we allow devs to opt-in to a set of leading edge changes.  Using command line or committed gradle.properties values doesnt work for that, unfortunately.

i asked developers to opt-in using their User Home Gradle

yeah, I think that's the only fallback.  I'll probably add manipulation of their gradle home properties into our opt-in/out tasks.  :disappointed:

You are asking how to produce an egg without a chicken. The scripts where you want to enable CC are not run with CC if reused, so enabling CC within them would be too late.

I'd imagine that would be true for everything except init scripts.  The same logic would apply for enabling parallel execution, however this works from init scripts.

Init scripts are invoked prior to project configuration so should be able to manipulate this

You don't listen, do you?
Init scripts are part of configuring the build.
If the configuration cache is reused, init scripts are not run but their effect reused.
So even an init script is too late to enable the configuration cache.
You can very easily test this with a `println("FOO")` within an init script.
The only ways are `gradle.properties`, command line arguments, or a custom build where you add any other way.

Parallel execution is galaxies far from configuration cache.
Parallel execution is an option that only affects execution phase where tasks from different non-coupled projects are then run in parallel.
Theoretically this option could even be switched during the configuration phase.

No need to be rude about a misunderstanding of what you were intending to convey

I trust what you are saying is true but the docs on this are sparse and/or misleading

I'm not rude, I just asked whether you listened to what I said as I had to repeat because you said the opposite of what I just told you.
If anyhting was rude, then that. :wink:

The documentation <https://docs.gradle.org/current/userguide/configuration_cache.html|says>:
&gt; The configuration cache is a feature that significantly improves build performance by caching the result of the <https://docs.gradle.org/current/userguide/build_lifecycle.html#build_lifecycle|configuration phase> and reusing this for subsequent builds. Using the configuration cache, Gradle can skip the configuration phase entirely when nothing that affects the build configuration, such as build scripts, has changed.
OP is trying to understand how the "configuration cache" caches something that's not part of the configuration phase, that's all

That's not at all what he asked though.
He asked "how to set it from code" and I said "it is not possible, not even from init script".
Then he said, "but it should work from init script" and I repeated that it is not possible from init script as it is also skipped when configuration cache is reused.

I agree that the documentation is a bit misleading or has potential for misunderstanding.
Init scripts as well as settings scripts are part of the initialization phase, not the configuration phase.
But the docs do not say, that the configuration phase is cached.
It says that the result of the configuration phase is cached.
This includes any earlier phases like the initialization phase in which init and settins scripts are run.
The result of the configuration phase are the tasks and their configuration and these are serialized to the configuration cache and on reuse restored from there.

&gt;  It says that the result of the configuration phase is cached.
That's precisely the issue.  By definition a cache is keyed based upon a particular input, that input _supposedly_ being the output of the initialization phase.  If there was no affordance for the inputs changing at all then the cached config would continue to be used indefinitely.  That's obviously not the case.   However, the current behavior is _not_ taking into account the full behavior of the initialization phase and is oversimplifying the calculation of the cache key.

By way of example, the init scripts are documented as being useful to:
&gt; • Set up properties based on the current environment, such as a developer’s machine vs. a continuous integration server. 
In this case, a property is exactly one of the documented controls for configuring the config cache. If the init scripts don't run then that control cannot be effected.   Hence, the surprise/disappointment.

I should back up a half-step fore completeness.  The inputs are documented as:
&gt; Build configuration inputs include:
&gt; • Init scripts, settings scripts, build scripts.
&gt; • System properties, Gradle properties, environment variables used during the configuration phase
&gt; • Configuration files accessed using value suppliers such as providers
&gt; • `buildSrc` build configuration inputs and source files.
The oversimplification being that the behavior of the `Init scripts, settings scripts, build scripts` is fully contained in their file content with no affordance for branching logic.

&gt;&gt; It says that the result of the configuration phase is cached.
&gt; That's precisely the issue.
I personally don't see any issue there, besides that it is possible it is misunderstood.
But feel free to open issues for things you think are wrong.
I'm just a user like you.
&gt; By definition a cache is keyed based upon a particular input, that input _supposedly_ being the output of the initialization phase.
This is neither said somewhere, nor is it implied anyhwere I can see.
&gt; If there was no affordance for the inputs changing at all then the cached config would continue to be used indefinitely. That's obviously not the case.
I'm not sure what you are trying to say.
Init script content is part of the cache key, as well as build script content, settings script content,
and all other things that make up the configuration cache input.
&gt; However, the current behavior is _not_ taking into account the full behavior of the initialization phase and is oversimplifying the calculation of the cache key.
Why do you think so?
The result of all phases up to before the execution phase are tasks and their configuration.
And that is what is saved to and restored from the configuration cache iirc.
&gt; By way of example, the init scripts are documented as being useful to:
&gt;&gt; - Set up properties based on the current environment, such as a developer’s machine vs. a continuous integration server.
&gt; In this case, a property is exactly one of the documented controls for configuring the config cache. If the init scripts don't run then that control cannot be effected.   Hence, the surprise/disappointment.
Well, you are taking it too literally, or rather interpret it too strictly to back up your anger.
That point just says that you can set up some properties based on the current environment.
You can then use these properties in your build scripts.
It does not say that you can change each and every property in an init script.
Actually, you _cannot_ set *any* Gradle property in an init script or build script or settings script and that statement also does not say so.
The only way to currently set a Gradle property is through `build.properties` files and `-P` commandline arguments.
And even if there were a way to set Gradle properties from an init script, there would be several ones that are simply impossible to set there as it is too late,
like for example `org.gradle.debug`, or `org.gradle.jvmargs`, or `org.gradle.java.home`, ...
You can often overlay Gradle properties by extra properties, but that also does only work if it is requested from the `project` like `project.property(...)` or similar,
but it will for example not work if the consumer uses `providers.gradleProperty(...)`.

&gt; I should back up a half-step fore completeness.  The inputs are documented as:
&gt;&gt; Build configuration inputs include:
&gt;&gt; - Init scripts, settings scripts, build scripts.
&gt;&gt; - System properties, Gradle properties, environment variables used during the configuration phase
&gt;&gt; -  Configuration files accessed using value suppliers such as providers
&gt;&gt; - `buildSrc` build configuration inputs and source files.
&gt; The oversimplification being that the behavior of the `Init scripts, settings scripts, build scripts` is fully contained in their file content with no affordance for branching logic.
What do you mean by "branching logic" here?
And of course the file content is not all that is considered I think, their classpath for example is for sure considered too.
If not, that is probably simply a bug.

&gt; Why do you think so?
&gt; The result of all phases up to before the execution phase are tasks and their configuration.
I think this entire discussion revolves around this point.  I agree that configuration implicitly relies upon the result of all phases prior.  That's where I see the problem: The result of the initialization phase is not being take into consideration because it is assumed that the result of the initialization phase (specifically WRT init scripts) cannot change without the init script content itself changing, whereas it may in reality take other data into consideration during its execution.  Thus, the cached configuration, if reused, is based upon an inaccurate representation of the initialization.

It's not really worth discussing further though.  It is what it is at this point: Gradle's behavior does not currently rerun init scripts prior to cache key computation.

Also, the only emotions I expressed were surprise and disappointment.  There is no anger here.

&gt; cannot change without the init script content itself changing, whereas it may in reality take other data into consideration during its execution
Well, if that is true, I'd say that is a bug or missing feature and you should report it.
After all, it is still an experimental features, so for sure still has some shortcomings.
I would for example expect that if you use otherwise auto-detected external information like for example system properties, environment variables, or system properties, they are used as CC inputs too automatically.
Or that you can define additional inputs like usual, using special providers methos or value source implementations.
I didn't play much with init scripts and CC yet, so I'm not sure whether these things work / are possible.
Can quite be that they are not yet possible or working, then you should open issues about them if there are none yet.

&gt; Or that you can define additional inputs like usual, using special providers methos or value source implementations.
I'm not _quite_ to 7.5 yet but am interested in trying this out exactly this when I get there.  It won't help my current conundrum but might ease the pain for more normal use in branching logic.

&gt; Thus, the cached configuration, if reused, is based upon an inaccurate representation of the initialization.
It's worth nothing that _init_ script don't only impact initialization. They can also configure the projects. There's some naming issues at hand that are making things more confusing

as in, init scripts don't only impact initialization.

True that.  Although the naming issue isn't present in this case, settings also has this same characteristic.  i.e., they both take part in initialization phase and beyond.

WRT init scripts, I haven't found a way to obtain an `ProviderFactory` instance (without deferring) so use of `ValueSource` instances (which would have to be inlined in the script itself) won't be an option.  This is probably worthy of raising an issue.

<https://github.com/gradle/gradle/issues/21517> raised

Inlined `ValueSource` implementations do appear to work correctly from init script, assuming the logic can be deferred until the `rootProject` has been created.

Unfortunately it seems the implied inputs like read environment variables, system properties and so on are also not considered when read from init script

Looks like there's an internal package that declares a `Transient&lt;T&gt;` base class

Hm… I don’t think we have test coverage for `ValueSourceParameters` with fields at all.

Elaborating on that, the expectation is that one can define new parameters using injected properties:
```interface MyParameters : ValueSourceParameters {
  val aStringParameter : Property&lt;String&gt;
  val aFlag : Property&lt;Boolean&gt;
}```


And some of those might be optional but not transient.

This might be a result of some task being marked `notCompatibleWithConfigurationCache`. We have a feature request to surface such tasks in the report, but it is not there yet ( I don't have any shortcuts for finding the offending task other than grepping the build sources, or, maybe attaching a debugger and setting a breakpoint on the method.

so when any task which declares `notCompatibleWithConfigurationCache` is present in the build whole configuration cache stops working? :thinking_face:

Not in the build, in the task graph.
If the incompatible task is not to be executed, there is no reason to not use CC

That's the point. The declaration means that the task cannot be (de)serialized properly, so if such a task is present in the graph, the graph would not be serialized. You can still get configuration caching for other graphs that don't include incompatible tasks. For example, you may have CC when running `test` but not when running `deploy` if the latter task is marked as incompatible

I see <https://github.com/gradle/gradle/issues/20673> ("Introduce mechanism to silence/ignore specific configuration caching problems") which would help in this scenario

I'm trying to make partial config cache compatibility safe for devs to use for the scenarios that have been fully corrected while we continue working with 2nd/3rd party plugin authors to correct remaining issues.

&gt;  Is there any mode of operation where config cache issues are detected and reported but do not cause the build to fail nor cause the invalid cache entry to be written to disk?
That’s the purpose of `notCompatibleWithConfigurationCache`
<https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:task_opt_out>

I was hoping for something which didn't require comprehensive evaluation of the build logic ahead of time.  Updating all of the involved plugins to flag the tasks as incompatible (or trying to do the same from tasks.withType / tasks.named etc) requires a lot of evaluation before we can release that which we know works.

I see. That’s a capability we’re currently lacking.

If someone follows the example from the kick-off to copy the wrapper to the snippet project,
instead of manually counting the directories up, one can use
```ROOT=$(git rev-parse --show-cdup) ...```
Another way would be
```$(git rev-parse --show-cdup)/gradlew wrapper```
but this needs significantly longer than just copying the files. :slightly_smiling_face: