Starting with Gradle 8.3, the *Configuration Cache* has been promoted to a stable feature. You can now turn it on in *gradle.properties* by setting *org.gradle.configuration-cache=true* Documentation on the Configuration Cache's performance impacts: docs.gradle.org/current/userguide/configuration_cache.html#config_cache:intro:performance_improvements
Thank you for complete review of Gradle's caching techniques! There is one thing, which puzzles me with "build cache" enabled is - how to --rerun integration tests (which depend on some external state (e.g. Docker-Compose)) if: 1) if those tests were already executed successfully, 2) and if the end user of the build uses a single lifecycle task to run tests? Suppose I have multiple "modules" ("Gradle projects", each having own test suites, some of them depend on Docker-compose). The regular flow for developers is to simply execute single ":testAll" task before pushing their code to CI. What if a user did some cleanup in containers by restating Docker-compose stack from scratch and wants to double check that all tests still pass? There is a '--rerun' option implicitly available for each individual task, but the problem here is that providing --rerun to lifecycle task won't affect the actual test tasks doing real job. To re-run tests in this scenario user will either have to use --no-build-cache, losing all benefits of build cache or to know what individual task on each sub-project to execute with --rerun. Would be great to know if there is a way to propagate the effect of --rerun from lifecycle task on tasks it directly dependsOn()
> but the problem here is that providing --rerun to lifecycle task won't affect the actual test tasks doing real job. Yes this is a shortcoming of Gradle. I think such a feature is missing. You have similar issues with other task-specific options like '--test'. The best "workaround" I know is to add a "-P" parameter (gradle property) for this yourself. Then users can do something like this: *./gradlew :testAll -PrerunTests* Then you would configure your test tasks to pick up the parameter. Something like: *tasks.withType().configureEach {* *if (providers.gradleProperty("rerunTests").isPresent) { inputs.property("time", Date().time) }* *}* (IntelliJ IDEA does something similar in the background when you press the test run button in the IDE.)
Thankyou for the excellent video Jendrik. When I migrated from maven to gradle, caching is one of those topics which really confused me. It took a long time for me to piece this information. This is a very crisp introduction to all the caches. Looking forward to more in-depth gradle concepts :)
Understanding Gradle is really helpful. thank you for making this playlist. by the way, i like your hair changing from #21, #22 and #23. It get shorter and shorter. just kidding :)
Very observant. 🙂Usually I record in the order I published, but 22 was indeed recorded some time before 21. I could pretend that I planned all this, but a haircut was just long overdue. 😀
@@SahilP2648 Sorry I don't know about any video specifically on that topic. As I mention in this video, you need: 1. A remote cache node running somewhere. You can find all installation and setup details here: docs.gradle.com/build-cache-node 2. Configure the remote build cache in you build: github.com/jjohannes/understanding-gradle/blob/main/23_Caching/my-project/settings.gradle.kts#L14-L21
Starting with Gradle 8.3, the *Configuration Cache* has been promoted to a stable feature. You can now turn it on in *gradle.properties* by setting *org.gradle.configuration-cache=true*
Documentation on the Configuration Cache's performance impacts: docs.gradle.org/current/userguide/configuration_cache.html#config_cache:intro:performance_improvements
Thank you for complete review of Gradle's caching techniques!
There is one thing, which puzzles me with "build cache" enabled is - how to --rerun integration tests (which depend on some external state (e.g. Docker-Compose)) if: 1) if those tests were already executed successfully, 2) and if the end user of the build uses a single lifecycle task to run tests?
Suppose I have multiple "modules" ("Gradle projects", each having own test suites, some of them depend on Docker-compose). The regular flow for developers is to simply execute single ":testAll" task before pushing their code to CI. What if a user did some cleanup in containers by restating Docker-compose stack from scratch and wants to double check that all tests still pass? There is a '--rerun' option implicitly available for each individual task, but the problem here is that providing --rerun to lifecycle task won't affect the actual test tasks doing real job. To re-run tests in this scenario user will either have to use --no-build-cache, losing all benefits of build cache or to know what individual task on each sub-project to execute with --rerun. Would be great to know if there is a way to propagate the effect of --rerun from lifecycle task on tasks it directly dependsOn()
> but the problem here is that providing --rerun to lifecycle task won't affect the actual test tasks doing real job.
Yes this is a shortcoming of Gradle. I think such a feature is missing. You have similar issues with other task-specific options like '--test'.
The best "workaround" I know is to add a "-P" parameter (gradle property) for this yourself. Then users can do something like this:
*./gradlew :testAll -PrerunTests*
Then you would configure your test tasks to pick up the parameter. Something like:
*tasks.withType().configureEach {*
*if (providers.gradleProperty("rerunTests").isPresent) { inputs.property("time", Date().time) }*
*}*
(IntelliJ IDEA does something similar in the background when you press the test run button in the IDE.)
Thankyou for the excellent video Jendrik. When I migrated from maven to gradle, caching is one of those topics which really confused me. It took a long time for me to piece this information. This is a very crisp introduction to all the caches.
Looking forward to more in-depth gradle concepts :)
Understanding Gradle is really helpful. thank you for making this playlist. by the way, i like your hair changing from #21, #22 and #23. It get shorter and shorter. just kidding :)
Very observant. 🙂Usually I record in the order I published, but 22 was indeed recorded some time before 21. I could pretend that I planned all this, but a haircut was just long overdue. 😀
@@jjohannes hey I am not clear about gradle remote caching. Can you link me some videos on how to use it properly?
@@SahilP2648 Sorry I don't know about any video specifically on that topic. As I mention in this video, you need:
1. A remote cache node running somewhere. You can find all installation and setup details here: docs.gradle.com/build-cache-node
2. Configure the remote build cache in you build: github.com/jjohannes/understanding-gradle/blob/main/23_Caching/my-project/settings.gradle.kts#L14-L21