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