Hi together, at my company, when we enable the gra...

# gradle

[Sebastian Lehrbaum]

Hi together, at my company, when we enable the gradle configuration cache (default enabled in gradle 9), we get an error from the compileKotlin task.

Execution failed for task ':compileKotlin'.
> Error while evaluating property 'disableMultiModuleIC' of task ':compileKotlin'.
   > Invocation of 'Task.project' by task ':compileKotlin' at execution time is unsupported with the configuration cache.

We traced it back to this line in the Kotlin compiler: https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-gradle-plug[…]ommon/kotlin/org/jetbrains/kotlin/gradle/tasks/KotlinCompile.kt

It only happens on jenkins, locally all is fine.
It is reproducible and happens in a cleaned workspace (also in a dirty one).

We are unsure why the error only happens on jenkins. Maybe a timing issue with the lazy? Any idea what that could be?

[tapchicoma]

are you disabling incremental compilation on CI?

[tapchicoma]

also please file a new Kotlin issue (ideally with repro) for this

[Vampire]

Actually, it seems unlikely to me that the mentioned line is the culprit.
While (practically always) a Property<Boolean> should be better, for example to wire the value lazily into some other property conveniently, by lazy should in this aspect here also be fine.
The result of the by lazy is calculated at the end of the configuration phase and put into the configuration cache entry, so at runtime the line you mentioned should not be executed.

You can easily test with

abstract class Foo : DefaultTask() {
    @get:Input
    val input: Boolean by lazy {
        println("input: ${project.name}")
        true
    }
}
val foo by tasks.registering(Foo::class) {
    doLast { println("foo: $input") }
}

You will see that the input line is only executed when the CC entry is calculated and if CC entry is reused, the result is taken from the CC entry.

[Vampire]

Actually, even without configuration cache I do not get a deprecation warning or error, because due to the @Input it is still evaluated early and does not trigger the check. Only if I make the property @Internal and disable CC, I get the deprecation warning that project is accessed at execution time.

[Sebastian Lehrbaum]

Incremental compilation is not disabled on CI. By default we do not clean our workspaces. Just for this issue we added a clean to make sure the bug is not due to incremental compilation.

[Vampire]

If that line were the culprit I actually would ask the other way around as disabled incremental should avoid that line, so the question would have been whether it is disabled on your local machines where the problem does not happen I guess

[Sebastian Lehrbaum]

Locally compiling with breakpoints show that incremental compilation is enabled. It only ever goes into the else branch.
I have a hard time reproducing the issue to create on Youtrack, since it does not happen locally. I was hoping someone have some idea how to create it locally.

[Vampire]

Maybe you have problem to reproduce because you have the wrong line in mind?
As I said, that line should never trigger project being referenced at execution time imho.
Can you gather a build --scan from the problem, or if not at least a --stacktrace?

[Vampire]

Maybe someone can get an idea from that

[Sebastian Lehrbaum]

Thats the stacktrace, it seems to clearly be this property. Seems like during the build it tries to fingerprint the input properties and that triggers the lazy calculation. I'm still trying to understand it deeper, honestly I don't even know what it means to be referenced at "execution time".

stacktrace.log

[tapchicoma]

please file a Kotlin issue with repro - we need to further investigate it on our side

[Sebastian Lehrbaum]

@tapchicoma trying to find a way to repro not on our jenkins

[tapchicoma]

if you will not be able to create a repro - just create an issue with stacktrace. Anyway invoking task.project in that place is suspicious and we should redo it

[Vampire]

I'm still trying to understand it deeper, honestly I don't even know what it means to be referenced at "execution time".

It means that while task logic is executed a call to Task#getProject was done which is deprecated without CC and an error with CC.

Anyway invoking task.project in that place is suspicious and we should redo it

Why do you think it is suspicious?
I don't see why the pure usage at that spot should be a problem.

How it is used is questionable though. 😄
Using a lazy API to eagerly get a value which will only work like expected if the value happens to be only calculated after all tasks were configured already.

[Sebastian Lehrbaum]

I have been unable to create an MRE. I created the issue here. There is no gradle project on youtrack, so I chose the Kotlin project.
https://youtrack.jetbrains.com/issue/KT-79047/Gradle-compileKotlin-fails-with-configuration-cache

[gmazzo]

FYI: We just got impacted on this in one of our CI in GHA after bumping to Kotlin 2.2.0 and enabling CC:

Error while evaluating property 'disableMultiModuleIC' of task ':gradle-plugins:o11y-support:compileKotlin'.
> Invocation of 'Task.project' by task ':gradle-plugins:o11y-support:compileKotlin' at execution time is unsupported with the configuration cache.

at

at org.gradle.api.internal.AbstractTask.getProject(AbstractTask.java:238)	
at org.gradle.api.DefaultTask.getProject(DefaultTask.java:59)	
at org.jetbrains.kotlin.gradle.tasks.KotlinCompile$disableMultiModuleIC$2.invoke(KotlinCompile.kt:431)	
at org.jetbrains.kotlin.gradle.tasks.KotlinCompile$disableMultiModuleIC$2.invoke(KotlinCompile.kt:425)	
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)	
at org.jetbrains.kotlin.gradle.tasks.KotlinCompile.getDisableMultiModuleIC(KotlinCompile.kt:425)

It's strange it only happens on CI, but not locally 🤔

[tapchicoma]

it would be nice if you could share a repro. Possibly the cause is only enabled when CI environmental variable is present

[gmazzo]

Let me see if I can manage to isolate it, this is a private repo. I can confirm adding --no-configuration-cache does workaround it

[Sebastian Lehrbaum]

As part of my attempts to create an MRE, I got the envs from Jenkins and applied them locally, but could not reproduce the issue. I don't think its an env variable.
One env variabel that I could not apply is the JAVA_HOME, as I cannot use the exact same jdk on the apple silicon.

[gmazzo]

By the way, we also bumped to Gradle 9.0.0-rc-3 is possible the CC deserialization logic has changed, and now an unresolved lazy is loaded instead of the actual value?

Nope, that will also trigger it on local

[tapchicoma]

СС serialized at the end of configuration phase so it should serialize the actual value of lazy

[madisp]

fwiw, we're hitting this as well, calling any publish* method in a Gradle 9 + Kotlin 2.2.0 project triggers this

[madisp]

will try to create a repro

[Rafael Chaves]

If you are seeing something like this at the end of the build:

`Configuration cache disabled because incompatible (feature|task) ... was found.``

then you are hitting this Gradle bug:

https://github.com/gradle/gradle/issues/34563

[Vampire]

Not really, are they?
With that message it should mean that the graceful degradation to CC disabled worked.
The issue you linked to says that the graceful degradation does not properly work in all cases and thus cause a build failure when it should have just been degraded to non-CC.

[Vampire]

Ah, no, it was gracefully degraded but then failed with that error, I see.