-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Gradle configuration cache #228
Comments
Hi, we're exploring configuration caching at SC; is this something you have planned on working soon, have an estimate you could provide, or a description of what prevents this work from happening? |
Hello, sorry for the late response. I can't give any promises, but I hope we can address this issue in 2021. |
As a little update on this: the gradle configuration cache currently is very unhappy about this plugin using buildFinished (https://github.com/jmfayard/refreshVersions/blob/main/plugins/core/src/main/kotlin/de/fayard/refreshVersions/core/internal/RefreshVersionsConfigHolder.kt#L132). I'll be trying to look into how this can be fixed. |
How is it unhappy? |
When running our project build (that makes use of refreshVersions) with --configuration-cache, this is the output: 2: Task failed with an exception.
1 problem was found storing the configuration cache.
See the complete report at file:https:///.../configuration-cache/as0e4uasippp0jkgc90s5xhk-1/configuration-cache-report.html
Note that Gradle is as helpful as ever, and I've had to actually jump into debugging mode with it to learn that it came from this plugin in our project. When running with configuration cache problems only shown as warnings, it technically caches it, but from experience with the build cache, it'll lead to some tasks not being re-run/run with the same configuration as previously. I am currently investigating how to remove those buildFinished calls, by registering a service with gradle that'll handle it, but since those buildFinished calls come from a place where there is no available Project, but just a ProjectDescriptor, this might get a little bit hairy. EDIT: nvm, it can be registered through settings too. I'll keep investigating and come back with findings. EDIT 2: That was surprisingly easy. Taking inspiration from what gradle-doctor did (runningcode/gradle-doctor@120d920), but by passing lambdas instead of requiring everything to be an autocloseable, allowing us to do any needed cleanup
then, in the places where
For tests, I had added a little bit of logging to ensure our lambda gets called, and it does. (Ignore the build failure, no phone plugged in):
Future runs do seem to reuse that cache:
Let me know if you'd like me to make this a pull request, or if you'd rather handle it/test yourself. |
Thanks for your research! My current focus is supporting automatic replacement of deprecated dependency notations, and it's a days long effort I'm trying to fit into my free time when I have the energy. Once I'm done with it, this issue will likely be top priority, besides updating some dependency notations in AndroidX again for new WearOS artifacts. |
Also, you should make sure to test config cache with every task that the plugin has. E.g.
Ideally this would be calculated at configuration time and passed an |
Hello, FYI, I'm working on this issue right now, and I expect it to take a few days to complete. If one of you want to join in a pair-programming session, let me know, I'll be happy to have one of you onboard! |
Thanks @pikzen for demonstrating it to work. I'll see if I can quickly handle the issue affecting the |
It's impossible (and pointless) to support Gradle configuration cache for the The main goal is to allow projects to take advantage of configuration cache safely, and this has been implemented successfully. |
Relevant documentation: https://docs.gradle.org/nightly/userguide/configuration_cache.html
The text was updated successfully, but these errors were encountered: