This message was deleted.

not sure what you're trying to measure, but perhaps try

./gradlew help --configuration-cache

?

We want a scenario that only execute the configuration phase.

./gradlew help

seems to work! The only issue is there is this log once the profiler pass from warm-up to measured builds 🤔

Calculating task graph as configuration cache cannot be reused because system property 'org.gradle.profiler.phase' has changed.

I think

./gradlew tasks

is also a good option, since it configures registered tasks. What is the reason you want to measure configuration phase with the configuration cache? Do you notice that configuration phase when there is a configuration cache hit is slow?

So far it was quite effective to detect a change that would break configuration cache and even before configuration cache we were measuring the actual configuration time. It could be easy to introduce regressions with a change in gradle task or add a 3rd party plugin, etc… Having it’s own scenario make the signal clearer to read.

There is the

--measure-config-time

command line option that captures the configuration time no matter which task you run. I suggest you run a task you care about, so the loading from CC measurement is more relevant.