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

Gradle Community

Ah, so no way for us, but you move them around, I see.
I hope we get it done before saturday or I have a hard time holding the review comment response time. :slightly_smiling_face:

If it is the weekend we would not hold you to the 48 hours. <https://github.com/gradle/cc-hackathon-2022/blob/main/rules.md|We reserved the right to deviate from the process when it makes sense>. Also Monday is a Holiday in the US.

Nah, more like 2 weeks Madeira without computer. :-)

wow nice! I will make sure the team sees it tomorrow then.

Yay, it's in, first to finish one :slightly_smiling_face:

About half the issues are done or claimed for our CC event! <https://github.com/orgs/gradle/projects/43/views/1> At only 6 days in if you are hoping to contribute and get swag you might want to get in there sooner than later.

I get lots of errors of this form:
```- Task `:services:deployment-validator:generateVersionTxt` of type `org.gradle.api.DefaultTask`: cannot serialize Gradle script object references as these are not supported with the configuration cache.
  See <https://docs.gradle.org/7.5.1/userguide/configuration_cache.html#config_cache:requirements:disallowed_types>
- Task `:services:deployment-validator:generateVersionTxt` of type `org.gradle.api.DefaultTask`: invocation of 'Task.project' at execution time is unsupported.
  ```

Please check <https://github.com/gradle/cc-hackathon-2022>

There’s <https://youtu.be/3L7-pGdCK3E|kickoff event> video that explains the way to resolve the issue

<https://www.youtube.com/watch?v=dDH3rNwMTQ0>

Using a `MutableMap&lt;String, Any?&gt;` works without any issues. Obviously it misses the ability to use `disallowUnsafeRead` and `finalizeValueOnRead`.

The collection properties have some fundamental strangeness to them that should be fixed. The `MapProperty` is probably the worst of them all, so it wouldn’t surprise me (I had a lot of issue using it). Your sample code is correct and they way you used it is also correct. I would also expect it to work without issues. First, I would make sure to try with the latest Gradle 7.x (and possibly with Gradle 8 nightly) to rule out that it’s an actual bug (not something that got fixed). Then, opening an issue would be quite valuable.

Hi Stephen, yes, that’s expected. The settings script is only evaluated during the configuration phase which happens as part of the 1st run only.

Whenever you use a build service you have to make sure that it is wrapped in a `BuildServiceProvider` or Gradle will try to serialize it. The easiest way in a task to achieve this is:
```class MyTask : DefaultTask() {
  lateinit var srv: Provider&lt;MyService&gt;
}

val srvProvider = gradle.shared...registerIfAbsent...

tasks.withType&lt;MyTask&gt;().configureEach {
  srv = srvProvider
  usesService(srvProvider)
}```
Obviously both `lateinit` and `var` look ugly and might be misused, an alternative:
```abstract class MyTask : DefaultTask() {
  abstract val srv: Property&lt;Provider&lt;MyService&gt;&gt;
}

val srvProvider = gradle.shared...registerIfAbsent...

tasks.withType&lt;MyTask&gt;().configureEach {
  srv.value(srvProvider).finalizeValue()
  usesService(srvProvider)
}```
*UNTESTED!*

I tried both of these approaches and I get the same error in both cases…

`BuildServiceProvider` itself has the following code:
```// TODO:configuration-cache - complain when used at configuration time, except when opted in to this
@SuppressWarnings("rawtypes")
public class BuildServiceProvider&lt;T extends BuildService&lt;P&gt;, P extends BuildServiceParameters&gt; extends AbstractMinimalProvider&lt;T&gt; implements Managed {```

What we've been doing was casting what is returned from `registerIfAbsent` to an actual `BuildServiceProvider` of the correct type. This allowed us to pass them on to worker actions. Maybe the same _hack_ is necessary for configuration cache compatibility?

```class MyBuildService : BuildService&lt;MyBuildService.Parameters&gt; {
  interface Parameters
}

typealias MyBuildServiceProvider = BuildServiceProvider&lt;MyBuildService, MyBuildService.Parameters&gt;

@Suppress("UNCHECKED_CAST")
val myServiceProvider = gradle.shared...registerIfAbsent... as MyBuildServiceProvider

class MyTask : DefaultTask() {
  val myBuildService: Property&lt;MyBuildServiceProvider&gt;
}```
Again *UNTESTED* and written from the top of my head.

That doesn’t seem to work either for me:
```Could not determine the dependencies of task ':services:notifications:notifications-dao:generateJooq'.
&gt; Could not create task ':services:notifications:notifications-dao:migrateDbTask'.
   &gt; Cannot set the value of task ':services:notifications:notifications-dao:migrateDbTask' property 'postgres' of type org.gradle.api.services.internal.BuildServiceProvider using a provider of type com.paxos.gradle.EmbeddedPostgresService.```

Well, the `EmbeddedPostgresService` is not a `BuildServiceProvider`, what is it?

I have a `Provider&lt;EmbeddedPostgresService&gt;` from `registerIfAbsent` that I am casting to `Provider&lt;BuildServiceProvider&lt;EmbeddedPostgresService, EmbeddedPostgresService.Params&gt;&gt;`

You need to cast it to `BuildServiceProvider&lt;EmbeddedPostgresService, EmbeddedPostgresService.Params&gt;` without the surrounding `Provider`. The signature of `registerIfAbsent` claims to return a plain `Provider` but it actually returns a `BuildServiceProvider`.

BINGO! success. Thank you very much <@U01A244DYUF>

I can’t help feeling this should have been documented somewhere….

What I don't understand is why it does not work without the cast. There should be some `instanceof` check somewhere for this, and that should evaluate to true as long as nobody turns that original `Provider` into something else.

Yes, <https://github.com/gradle/gradle/issues/19782>. We have improved the test launcher API so IDEA won’t have to rely on changing init scripts going forward.

oh yes I looked into this the other day. its madness how tests are captured by default. is there committment from idea to switch to the tooling api test launcher from the idea team? I havn't heard back from them when I asked at slack a few weeks before

The IntelliJ IDEA devs are planning to use the Tooling API (TestLauncher) to run tests, at least for Gradle 7.6 and onwards. That will remove a lot of configuration cache misses when running tests from the IDE. Work in progress, but no ETA.

You can follow this one: <https://youtrack.jetbrains.com/issue/IDEA-232317>

I can only guess their internal processes, but they’ll probably update the issue when they are confident that the changes will be included in a particular release.

What kind of work would you want to do on a build that has no task work to perform?

Just call get on the provider in your plugin or build script.

&gt; What kind of work would you want to do on a build that has no task work to perform?
write reports

&gt; Just call get on the provider in your plugin or build script.
I've tried - didn't work. Which is logical as plugin configuration is skipped on configuration cache reuse

What do you mean with _plugin configuration_? The `apply` function in a plugin should always be called, otherwise the tasks that Gradle needs to find out if something changed would never get registered. What is probably happening is that the project you are running it against never gets evaluated, because it's not needed. Do you have a minimal reproducer?

just checked - plugin `apply()` method is not called on configuration cache reuse

Is the project being evaluated? Is it the root project? Gradle won't call the `apply` function if it never evaluates the project.

Untitled.txt

On configuration cache reuse Gradle does not reevaluate the project if nothing was changed

Your log is showing exactly what I'm getting at. It never evaluates the `simpleProject` because there is no task requested for the project. If you want your plugin to always be executed apply it to the root project, or turn it into a settings plugin.

`simpleProject` is a single project :slightly_smiling_face:

How settings plugin will help here? I suppose if settings classpath was not changed - Gradle will also skip settings evaluation :thinking_face:

Just throw a `println("hello")` into your settings script, it is always going to be printed, always. Same goes for the build script of your root project. Now replace the `println` with `gradle.sharedServices.registerIfAbsent(...).get()` and your build service is always created, always.

I've thrown `println("hello")` into `settings.gradle` and build on configuration cache reuse does not print "hello" :man-shrugging:

&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.
&gt; 
&gt; — <https://docs.gradle.org/current/userguide/configuration_cache.html>
Yeah, seems like the scripts themselves are cached away as well. It actually makes sense to force people to turn their builds into side effect free builds. Well, I guess you're out of luck (for good reason).

Proper fix - service should implement `OperationCompletionListener` and register itself to <https://docs.gradle.org/current/javadoc/org/gradle/build/event/BuildEventsListenerRegistry.html|BuildEventsListenerRegistry>

What kind of report are you creating so that you need it even if nothing executed? Some kind of performance measuring?

i had issues with Gradle Enterprise scans not sending our custom data when it was being added in `buildSrc` , I was able to get around it by creating a plugin to do that which I'm appying in `settings.gradle`

Vinay, have you seen this? <https://github.com/gradle/cc-hackathon-2022/blob/main/faq.md#why-cant-i-reproduce-an-issue-using-the-command-line-snippet-provided-in-the-github-issue|https://github.com/gradle/cc-hackathon-2022/blob/main/faq.md#why-cant-i-reproduce-an-issue-using-the-co[…]-line-snippet-provided-in-the-github-issue>

On that note, I cannot reproduce it either. Let me dig a little more.

Please see <https://github.com/gradle/gradle/issues/21803#issuecomment-1248031565>

Note that issue has already been claimed by <https://github.com/cguerreros>

There are currently 3 issues on the Unclaimed column on the hackathon board:

<https://github.com/orgs/gradle/projects/43/views/1>

Yes I made sure to keep in sync with master branch.
Also I’m just picking a random issue just to get an idea before assigning a new one.

I’m able to reproduce this <https://github.com/gradle/gradle/issues/21811|issue 21811> though. Will work on this.

Afaik no, because the `gradle` object decides when to evaluate a project and can thus execute arbitrary code before it starts the actual evaluation. This is different to one `project` object reaching out to another `project` object. An analogy I can think of is that `gradle` is the executor, and the projects are `threads`. Again, afaik, someone who is more knowledgeable on this shall correct me if I'm wrong.

looked for this issue but couldn't find one, so I created it. Apologies if it's a known thing. tl;dr `gradle init --configuration-cache` doesn't work in 7.5.1. <https://github.com/gradle/gradle/issues/22188>

Untitled_kt.kt

a bit more context - I use a bunch of Gradle properties to lookup a series of APKs (that are already externally built), and run these files as inputs to a `Sync` task into another directory

Because I can’t get a `RegularFile` from a `String` out of the `ValueSource` API - I’m using the `String` s from these gradle properties as input to the `Sync` task instead of the files themselves.

I don’t know why, but when I re-use the config cache and I manually delete the input or output files, the `Sync` task skips execution due to `NO-SOURCE`. This only happens when the config cache is re-used.

The inputs to the `Sync` task are still the same `String` values (as the gradle properties that create that `String` value have not changed, but the input files are deleted. Additionally, manually deleting the output (`into(..)`) folder of the `Sync` task has the `NO-SOURCE` problem too.

smells like you shouldn't be using a value source to represent a file and the api's being difficult is the right thing here.

Should prob be an `@Classpath` or `@InputFile`

maybe just my hot take on what I am reading.

We're working on improving this use case right now, by having a better guidance in the docs, better error reporting, and supporting more cases where possible. Currently, it isn't possible to call methods defined in the build script, you can work around this by making them static methods of some class.
For example, this won't work:
```def printFoo() {
    println "foo"
}

task check {
    doLast {
        printFoo()
    }
}```
But this would:
```class Foo {
    static def printFoo() {
        println "foo"
    }
}

task check {
    doLast {
        Foo.printFoo()
    }
}```
The relevant issue is <https://github.com/gradle/gradle/issues/20126>

Of course, if `printFoo` invokes methods of `Project`, it won't work properly, for the same reasons `Task.getProject` is disallowed at the execution time when configuration caching is enabled

Thank you a lot. Let me try if I can do more with it

This (using `Set&lt;FileSystemLocation&gt;` instead of `FileSystemLocation`), however works:
```fun TaskProvider&lt;Sync&gt;.asFileSystemLocationSet(): Provider&lt;Set&lt;FileSystemLocation&gt;&gt; {
    return map {
        it.outputs.files.asFileTree.elements.get()
    }
}```
I think this is because Gradle understands that the `Set&lt;..&gt;` is live, and pulling a single `FileSystemLocation` out of it breaks that behavior

However - I don’t want to define my task input as `Set&lt;FileSystemLocation&gt;` when it’s only 1 file - I want to define it as `FileSystemLocation`

Perhaps the following would work:
```fun TaskProvider&lt;Sync&gt;.asFileSystemLocationSingleFile(): Provider&lt;FileSystemLocation&gt; {
    return flatMap { sync -&gt;
        sync.outputs.files.asFileTree.elements.map { it.first() }
    }
}```

The `asFileTree` step looks redundant:
```fun TaskProvider&lt;Sync&gt;.asFileSystemLocationSingleFile(): Provider&lt;FileSystemLocation&gt; {
    return flatMap { sync -&gt;
        sync.outputs.files.elements.map { it.first() }
    }
}```

I’ve had so many issues with flatmap tbh bc it switches the provider and seems to break the chain of dependent tasks, but I’ll try it

```fun TaskProvider&lt;Sync&gt;.asFileSystemLocationSingleFile(): Provider&lt;FileSystemLocation&gt; {
    return flatMap { sync -&gt;
        sync.outputs.files.asFileTree.elements.map { it.first() }
    }
}```
worked! Needed to use `.asFileTree` to get the actual file output instead of the directory

hmmm.  that error message appears to be more about the Task object itself, rather than what may be captured.  Do you have the full stack trace?

thx.  what does the build.gradle look like?  (presumably this is where the custom task is registered)

Yes, of course. This was generated with the standard GradleRunner test the gradle init spits out

So the functional test example generated by gradle looks like
```        buildFile &lt;&lt; """
plugins {
    id('gradle.plugin.closure.issue.greeting')
}
"""```

And the plugin registers it’s tasks like
```        project.tasks.register("issue", GradlePluginClosureIssueTask) { GradlePluginClosureIssueTask task -&gt;
            task.doLast {
                println("Ran gradle issue task")
            }
        }```

ah, groovy.  try this:
```project.tasks.register("issue", GradlePluginClosureIssueTask) {  task -&gt;
            task.doLast {
                println("Ran gradle issue task")
            }
        }```

the
```	at gradle.plugin.closure.issue.GradlePluginClosureIssueTask$_closure1.doCall(GradlePluginClosureIssueTask.groovy:14)```
line is
```            if (getSomeData() != null) {```
in the task

The configuration closure doesn’t need lambda syntax.
```project.tasks.register("issue", GradlePluginClosureIssueTask) {  
            doLast {
                println("Ran gradle issue task")
            }
        }```

It did in this tasks case since I have the `@CompileStatic` annotation on the plugin. Removing it made the compiler error go away, but not the task cast error

Oh, ok so I removed the CompileStatic from the task as well, and got a different error.

```&gt; Could not find method getSomeData() for arguments [] on task ':issue' of type gradle.plugin.closure.issue.GradlePluginClosureIssueTask.```

ah, ok.  interesting.  the method is there, though it’s called inside other closures.  Is that the only call to it (in the constructor)?

In this trivial example, yes. In a plugin I’m working on no

possible to rework your trivial example to use Kotlin?  It offers far better type-safety and helpful error messages for cases like this.

The trivial example looks like it works when I rewrote it in java at least

cool.  likely some subtle Groovy-ism there then.

bmushko’s gradle docker plugin is massive and written in groovy tho, which makes a rewrite a bit more daunting :wink:

yea.  have incrementally moved a few plugins from groovy to Kotlin.  First step is to ensure you use Action&lt;WhateverClass&gt; instead of Closure - this helps both with interop within the plugin, and ease of use for Kotlin DSL consumers of the plugin (they shouldn’t have to see the Groovy closure stuff).

See <https://github.com/allegro/axion-release-plugin> as an example of mixing Groovy and Kotlin.

At least for this task, I was trying to get a reproducer together to maybe report to the gradle team.

```outputs.upToDateWhen {```
by default in groovy that syntax will call the Closure override

If you write a similar call in java or kotlin, it’ll choose the Spec&lt;Task&gt; functional interface override instead

Manually specifying
```outputs.upToDateWhen(new Spec&lt;Task&gt; { .......```
in groovy makes the whole thing work

interesting.  Does this (or some variation) work:
```outputs.upToDateWhen( Spec&lt;Task&gt; {```

you may also be able to cast it to get the right override.

I tried the most groovy-esque equivalent I could find which was
```outputs.upToDateWhen {
} as Spec&lt;Task&gt;```
and that failed too

also tried
```Spec&lt;Task&gt; upToDateWhen = { Task task -&gt;
    if (getSomeData() != null) {
        return true
    }
    false
}
outputs.upToDateWhen(upToDateWhen)```
which pretty much makes up every syntactical variation I could come up with

yea.  unfortunately that’s beyond my Groovy-fu, haven’t touched it much in a couple of years.

that’s good, if it were fully accurate.  If you *write* a file inside a ValueSource - standard FileOutputStream stuff - that invalidates the configuration cache.
```Calculating task graph as configuration cache cannot be reused because file '../../../../.cloudshift-gradle/.cloudshift-codeartifact.properties' has changed.```
…all that code is inside a single ValueSource.

In this case, the writing of that file has no bearing on what the ValueSource returns - would prefer to not invalidate the cache.

You might have found a bug.
Iirc things like reading files, reading system properties, and so on, should not cause configuration cache to be invalidate if done inside a value source implementation but should be auto-detected outside.

Maybe that writing is not handled as exception?

But actually my guess would have been that this file is somewhere read as input for configuration cache and that it is not the writing of the file in the value source, but the reading as input invalidates the cache actually. But that's just a wild guess without analyzing the build.

possibly a bug, though the `ValueSource` docs hint that it’s only reading:
&gt; A value source implementation is exempt from the automatic detection of work graph cache inputs. For example, if the `obtain()` method calls `System.getenv("FOO")` then changes to the `FOO` environment variable only invalidate the cache if the value returned by the `obtain()` method itself changes. The same applies to reading files or system properties.
That file is used in one class (read and write), buried way down deep inside a ValueSource call hierarchy.

trying to track down how/where Gradle instruments code to detect file/property/env access…

Byte code manipulation in `org.gradle.internal.classpath.InstrumentingTransformer`,  Not seeing anything for writing in there.  It’s possible that the pattern being used to read/write isn’t properly caught by the instrumentation.

Ok, so - was able to reproduce. tl;dr - you can’t pass a ValueSource (including `providers.environmentVariable` or `providers.gradleProperty` as an input parameter to another ValueSource.
In digging through the internals, the logic works as:
a) Transforming classloader (`org.gradle.internal.classpath.InstrumentingTransformer`) - finds all kinds of relevant code (such as file open, get env variable, etc) and rewrites the code to emit events
b) event handler (`org.gradle.configurationcache.fingerprint.ConfigurationCacheFingerprintWriter`) stores these changes _conditionally_; the conditional is based on a ThreadLocal variable `inputTrackingDisabledForThread`
c) when a value is obtained from a ValueSource, it first emits a `beforeValueObtained()` event; this sets the input tracking OFF
d) value is obtained from ValueSource
e) ValueSource emits `afterValueObtained()` event; this sets the input tracking ON

The problem comes when using a ValueSource (such as a Gradle property) as an input parameter to your ValueSource (it may be if there are an odd-number of ValueSource parameters) - the fingerprinting of those inputs resolves the values, and leaves input tracking ON for the body of your ValueSource.  Ouch.

Will get the repro cleaned up and an issue created in the morning.

Repro: <https://github.com/cloudshiftinc/repro-gradle-configuration-cache-value-source>

Issue: <https://github.com/gradle/gradle/issues/22305>

Oh, so the "is tracking" is not a counter but a boolean. Nice find.

This gives me a configutation-cache problem (cannot serialize ProcessResources):
```inputs.files(tasks.named('processResources')).withPropertyName('processResources outputs').withPathSensitivity(PathSensitivity.RELATIVE)```

But this seems too verbose:
```dependsOn tasks.named('processResources')
	inputs.dir(sourceSets.main.output.resourcesDir).withPropertyName('processResources outputs').withPathSensitivity(PathSensitivity.RELATIVE)```

Without the dependsOn I get the ususal warning about undeclared task dependencies.

The following also seems to work (at least there are no warnings), but is not exactly concise, either. Is that the best we can do?
```tasks.named('processResources').map {
	inputs.dir(it.outputs)
			.withPropertyName('processResources outputs')
			.withPathSensitivity(PathSensitivity.RELATIVE)
}```

It seems that a `fileTree` created in a `settings.gradle.kts` script (either via `settings.fileTree` or `gradle.serviceOf&lt;ObjectFactory&gt;().fileTree()`) is entirely ignored by the configuration cache. Changes on the file system are never picked up, and the cache is always considered up-to-date. :thinking_face:

system properties and environment variables are not the same thing

correct.  the point was that going directly to the source - bypassing ValueSource providers - works.

Ah I see, not the difference in property vs env var but rather ValueSource and project.provider calls

Iirc they were compatible before if not even introduce because of CC, but I think what changed is, that the auto-detection of CC inputs like read properties, read files, and so on is disabled within the value source value calculation. (Except if you have one value source backed property as input to the value source as there is a bug that the disabling of the detection is quit before the actual value is calculated)

yeah, in my case I want to read `local.properties` via `ValueSource` but Gradle 7.3.3 complains about it

Adding `.forUseWithConfigurationCache()` doesn't help either

Here is the message:
```Cannot obtain value from provider of Kotlin_bootstrap_settings_gradle.PropertiesValueSource at configuration time.
Use a provider returned by 'forUseAtConfigurationTime()' instead.```

and here is the `ValueSource` code:
```abstract class PropertiesValueSource : ValueSource&lt;Properties, PropertiesValueSource.Parameters&gt; {
    interface Parameters : ValueSourceParameters {
        val fileName: Property&lt;String&gt;
        val rootDir: Property&lt;File&gt;
    }

    override fun obtain(): Properties {
        return parameters.rootDir.get().resolve(
            parameters.fileName.get()
        ).bufferedReader().use {
            Properties().apply { load(it) }
        }
    }
}```

Hm, not sure.
Did you try to use the `forUseAtConfigurationTime()` on both those properties?

More code:
```private val localProperties = providers.of(PropertiesValueSource::class.java) {
    parameters {
        fileName.set("local.properties")
        rootDir.set(settings.rootDir)
    }
}

val customBootstrapRepo = localProperties
    .map { it.getProperty(Config.REPO_KEY) }
    .orElse(providers.gradleProperty(Config.REPO_KEY))
    .forUseAtConfigurationTime()```
Gradle complains when `customBootstrapRepo.orNull` is called

I suspect that `forUseAtConfigurationTime` is not propagated upstream, so you have to sprinkle it onto every "unsafe" provider:
```val customBootstrapRepo = localProperties
    .forUseAtConfigurationTime()
    .map { it.getProperty("someProperty") }
    .orElse(providers.gradleProperty("someProperty").forUseAtConfigurationTime())```
at least, that's my reading of the forUseAtConfigurationTime code

sounds like you might be seeing this (resolved in Gradle 8)? <https://github.com/gradle/gradle/issues/19252#issuecomment-1275805377>

Gradle 7.5.1 doesn’t complain about it.

You can mark task you discovered that are incompatible with `notCompatibleWithConfigurationCache("incompatible with Gradle configuration cache")`if that's what you mean

Doesn't help for plugins though that for example use forbidden listeners and so on.

<@URQ797WRW> really true that statement, I can't use configuration cache yet due plugins that are using grgit for example

In a way. Gradle is using reflection to read and serialize the fields of `SerializedLambda`when it could be using the exposed API.

I'm not sure how I can workaround this. I have added `serializableFunctionOf`, `serializableTransformerOf` etc around lambdas in my plugin :confused:

I guess the issue is that one serialized lambda uses `collect(...)` and that collector cannot be serialized.

Ok I have found a workaround for this one by not passing the collector as an argument, on to the next error...

does that ring a bell?
```Caused by: java.lang.ClassCastException: class org.gradle.api.internal.file.DefaultFileCollectionFactory$ResolvingFileCollection cannot be cast to class org.gradle.api.artifacts.Configuration (org.gradle.api.internal.file.DefaultFileCollectionFactory$ResolvingFileCollection and org.gradle.api.artifacts.Configuration are in unnamed module of loader org.gradle.internal.classloader.VisitableURLClassLoader @4cdf35a9)
        at org.graalvm.buildtools.gradle.NativeImagePlugin.$renamedDeserializeLambda$(NativeImagePlugin.java:153)
        at org.graalvm.buildtools.gradle.NativeImagePlugin.$deserializeLambda$(NativeImagePlugin.java)
        ... 170 more```

(sorry no scan because.... happens at configuration time!)

this seems to be caused by this call:
&gt; Set&lt;ResolvedComponentResult&gt; components = classpath.getIncoming().getResolutionResult().getAllComponents()

It looks related to how the configuration cache serialization turns `Configuration` objects into simpler `FileCollection`s

Any implicitly captured variable holding a `Configuration` instance must be explicitly typed as `FileCollection`

Note that I'm using serializable lambdas, but the last error looks like a Gradle bug, isn't it?

I was able to work around it so far by setting imageId based off the output imageIdFile
```imageId.set(imageIdFile.map { RegularFile it -&gt;
    File file = it.asFile
    if(file.exists()) {
        return file.text
    }
    return null
})```
But I’m not sure if this approach is the best one

A task can only have defined fine outputs, hence this trickery with the `imageIdFile` and `imageId`. But I actually wonder how CC should influence this, as `imageId` is an execution time thing. It is set during execution or during `outputs.upTpDateWhen` such both run after the cache configuration phase.

this may be best in <#CJYS1DAP5|> channel though this is both :shrug: . have you tried a newer version of gradle like 7.5.1

Maybe it’s worth sharing your use case here: <https://github.com/gradle/gradle/issues/22514>: