-
Notifications
You must be signed in to change notification settings - Fork 461
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
Gradle build cache miss due to volatility of SpotlessTask.steps input #2168
Comments
Thanks for this report! We have gone to great lengths to make our step's equality correct, but Our current implementation puts all of each task's implementation details into account. Settings files, flags, etc. If you change a formatter's setting file, you want the formatter to rerun, you don't want to clear cache before you can find out what the new flag does. I see this problem is present in |
Sorry for the late reply @nedtwigg The cache key differs when running the build from different locations due to a change in the underlying fingerprint of FormatterStepSerializationRoundtrip.roundtripStateInternal This is specific to the Serializing EquoBasedStepBuilder has some references on a settings file with an absolute path. This can be fixed by configuring the collection transient and adding a collection that would represent this input without volatility (Collection of file names?). |
Huh. So the point of this: spotless/lib/src/main/java/com/diffplug/spotless/FormatterStepSerializationRoundtrip.java Lines 27 to 29 in 059523c
Is that there is a The state which is used to calculate spotless/lib/src/main/java/com/diffplug/spotless/FormatterStepSerializationRoundtrip.java Lines 44 to 50 in 059523c
This is what I thought that the convoluted design above would let us satisfy the convoluted requirements the Gradle's configuration cache forces on us:
One of two things is going on:
Any chance you can provide the filename in question? |
I can confirm that the You can see in this screenshot the absolute path to the settings file (in addition to my proposal of adding a collection containing only the filenames) It is configured here in the consumer project. Unrelated to this issue, while investigating the problem I discovered that |
any chance you could consider this option @nedtwigg ? If not, will you implement a fix? |
Re:
I just added a test to show a few things:
spotless/lib-extra/src/test/java/com/diffplug/spotless/extra/java/EclipseJdtEqualityTest.java Lines 35 to 47 in 53a2c48
From the docs for Gradle build cache:
So now the question is: is Gradle doing the exact same hack we did before this gigantic 7.0 epic? As in, they are using the serialized representation to do |
Yeah, looks like there's a fundamental conflict here. Gradle uses the serialized representation of your task to do build cache, it does not respect As it stands in spotless 7.x, local build cache and local configuration cache both work, but shared build cache is broken. In 6.x, everything worked except that the local configuration cache barfed if you started a new daemon.
|
|
Great job @nedtwigg, the 7.0.0.BETA3 indeed fixes the issue |
The issue is reproducible with release version of the 7.0.0 plugin and gradle 8.9:
|
@gendolf3d your issue seems like something new, feel free to open an issue if you have a reproducer |
Summary
any
7.0.0.BETA1
any
Spotless configuration
See this example in the JUnit5 project
Expected behavior
Run the build twice without changing the code and get a Gradle build cache hit on
spotlessJava
taskCurrent behavior
A cache miss occurs in the second build scan
First Build Scan®
Second Build Scan®
Due to the SpotlessTask.steps value being different in the two builds:
Steps to reproduce
Reasons
The SpotlessTask.steps is declared as task input but deserializing/serializing the collection is not consistent
Fix
Use a consistent representation of the input by using the steps name.
This assumes that the step name is unique.
See this Build Scan®️ illustrating the build cache hit with the fix
The text was updated successfully, but these errors were encountered: