Support Configuration Cache with Gradle 8.1 #221
Comments
|
Thanks for the build scan. Do you have a corresponding scan with 8.0? I assume, the release process worked fine with 8.0? |
Please upgrade to 1.3.0. In 1.2.0 there were some deprecation warnings fixed. |
|
Thank you for the fast response. Gradle 8.1.1 and Configuration Cache enabled: failure: https://scans.gradle.com/s/h5sldg3zjwzec The failure with Gradle 8 was primary due the missing signing support, which was fixed with Gradle 8.1. |
|
Yes, I see that 8.1 helped with many issues in the Gradle core plugins. I had a quick look at the remaining output and:
seems to be caused by the fact that our tasks effectively extends The javadoc for that annotation states: Could you use Btw, does the project build and release fine with 8.1 if
is caused by the issues with cache or something else. |
|
I don't get it: I fixed the Now I "just" get the error, the nexus plugin isn't compatible with the config cache: https://scans.gradle.com/s/cucwn35lmbmuo I will upload the configuration cache error file soon. |
|
Added the configuration cache html report for this build scan https://gradle.com/s/cqgbqyvimhm2c |
TWiStErRob
added a commit
to TWiStErRob/repros
that referenced
this issue
May 25, 2023
|
I had a quick look out of curiosity, I haven't got too far, but here's my thoughts anyway: InvestigationLooking at the HTML and expanding first tree element fully I still see:
Based on that I think this lazy value: is being queried in order to store the configuration cache, but that probably shouldn't happen. I have a feeling even if this exception wasn't thrown here the problem of serializing Tasks will come up. Note: is and the field removed. EDIT: oh! this is Gradle task, not from this plugin, so the next question is even more relevant: But even if that solves a problem, why is an instance of I also made a repro project:
(Dry run will not execute tasks, because the Nexus setup is bogus, but that doesn't matter because we want to test the code that runs before the EXECUTION phase.) To consume a local build add to settings.gradle.kts: |
|
I dug much deeper into the problems listed here are some findings:
If we filter the stack trace it makes more sense: The key here is that in order to serialize the repository, we need to have its URL ready. But the URL is only available after a task that initializes the repository has been executed. This is where I need domain knowledge help @szpak: is it possible to add these repositories after their URLs are resolved? I think the root cause here is that |
|
I think another root cause of this error seems to be that Maven Publish plugin is partially supported.https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:plugins:core
They might be referring to this problem with that warning icon. @hfhbd What do you think, what's your read of the my findings? Based on this any change to this plugin might be just a workaround / hack of Gradle partial support. |
|
Thanks for the analysis. |
|
@TWiStErRob Thanks for your insightful analysis!
I would be problematic. For every repository the tasks are created: The tasks (and their orchestration) cannot be created after the execution of the initialization task, so we could need to have some "temporal structure" without URL to have it serialized and somehow add and keep the URL later on there it is needed. gradle/gradle#22779 should solve it in a better way. #223 looks good, I will merge it right after a bigger #222 to avoid potential conflicts there. |
|
Update: gradle/gradle#22779 is scheduled for Gradle 9 (for now). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
AFAIK this is my first release after updating Gradle to 8.1.1: https://scans.gradle.com/s/rdlhgp2eynkr4
The build contains ~30 jvm only modules.
The text was updated successfully, but these errors were encountered: