is there a flag, that I can use to enable configuration cache inside build script? My idea is, to di...

# gradle

[Peter]

is there a flag, that I can use to enable configuration cache inside build script? My idea is, to disable it on CI something like this: isConfigurationCacheEnabled = !System.getenv().containsKey("CI")

[Javier]

Run it on CI with

—-no-configuration-cache

[Peter]

I kind of wanted to avoid that, since I think I would need to copy-paste on multiple places in my CI script

[Vampire]

Why should you want to disable CC on CI?

[Vampire]

Even if it is not reused as you do not preserve the CC entries between runs, you still gain performance as with CC each and every task can run in parallel (given they have no ordering relation)

[Vampire]

Besides that the question has nothing to do with Kotlin and thus is off-topic here. 😉

[Peter]

I had some issues with slow CI builds. Disabling that fixed the issue.

I thought I read from documentation that disabling that on CI was recommendation 🤔

[Vampire]

That's in the adoption steps, which probably were written with CC being new and many plugins not supporting it, trying to be more stable on CI.

But in the meantime, and especially with the parallel execution, I don't think this is a valid recommendation. I'd tend to say that this part of the docs is outdated or at least should get some more clarification.

Also, with Gradle 9 CC will be enabled by default: https://github.com/gradle/build-tool-roadmap/issues/75. I highly doubt they would do that if it is discouraged to be enabled on CI.

Similarly, it was recommended in the past to disable the daemon on CI, which also is not the case anymore.

[Vampire]

But to also answer your initial question, it is by fact absolutely impossible to enable or disable CC in the build script or even an init script. Everything up to the execution phase is skipped if the CC is reused, so there is no way to dynamically determine whether the CC should be used. Not from within Gradle that is. If you call the wrapper script on CI, you could maybe customize the wrapper script to do the determination. Other than that, you probably would have to use a custom distribution that behaves like you want. But it most probably really is better to keep CC on and if there are performance problems, fix or report them.

[Peter]

I see. Thank you for answers guys!