https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
c
The only difference with a successful run is the `notCompatibleWithConfigurationCache`:
Copy code
tasks.withType<org.jetbrains.kotlin.gradle.targets.js.ir.KotlinJsIrLink>().configureEach {
    notCompatibleWithConfigurationCache("Sabotage")
it's a false positive, but maybe there is a reason for it that I can't see
m
That is https://github.com/gradle/gradle/issues/22481#issuecomment-1673599544. It has been known for a while but there's no remedy at the moment.
😭 1
c
There is no 
enableFeaturePreview("STABLE_CONFIGURATION_CACHE")
in this case
v
But the same effect produced by bullet point 3. Enabled CC with an incompatible task in the graph.
c
exactly, but..the issue is inaccurate then
v
Kind of, and kind of not. :-D As CC is not used, state is not persisted and restored, so 
project
is accessed at execution time and while CC is not used, it nevertheless is enabled and thus accessing 
project
at execution time is forbidden. 🤷‍♂️
c
Thanks for the explanation, even if it was already clear I guess I can work with this... in any case false positives like this are terrible (that's my frustration talking, I know)
v
It's probably anyway not the best idea to access an extension of the root project from a task in potentially another project. Latest with project isolation this for sure becomes a problem.
Maybe you instead need a shared build service that holds the data you need from multiple projects / tasks and configure that service from the extension or something like that
c
of course, I saw the task and we need to rework it The issue is that while enabling CC I'm discovering random issues, and the report is misleading.
Thanks a lot for your help anyway.
👌 1
2 Views
Open in Slack
PreviousNext
Powered by