Hi, we are experimenting with the build cache and so far the results are good on linux. Although we have some problems to get good cache hits between our windows and linux builds that build exactly the same code. At first we had 0% hits, after changing some gitattributes the source files are now having the same line endings (LF) en we now have cache hits for
compileTestJava which is great. Although we are not sure if we really want to have LF Lin endings on both java and linux since this brings us some other practical problems, so I wonder gradle will ever be made a bit smarter to ignore line endings when comparing? I understand this is not really a problem related to gradle, although it would be nice if I do not have to care about this.
javadoc we have more problems to get cache hits. I found that the classpath input property on
javadoc task is the only property that had a different build cache key comparing windows and linux:
13:50:35.100 [DEBUG] [org.gradle.caching.internal.tasks.DefaultTaskOutputCachingBuildCacheKeyBuilder] Appending inputPropertyHash for 'classpath' to build cache key: 18cb8dc9851080210ce60f2e78e8130e
Wen debugging the classpath, both seems to be equivalent, I mean, paths are different etc, but not really something that should matter. Even the order is the same.
How is the classpath property exactly hashed and compared on test and javadoc? And how is this different from compile because there is seems to work properly.