https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# caching
s
This message was deleted.
f
Have you enabled capturing task inputs for the builds? It should let you compare differences
Also newer versions of GE have better tollchain support so consider updating
c
often JVM provider/version/arch differences play a role in GE cache misses
c
Have you enabled capturing task inputs for the builds? It should let you compare differences
is this different from showing the cache key of each input? GE tells me that 
kotlinJavaToolchainProvider
input cache key is different but I don't know why it is
The strange thing is that I'm getting misses but a colleague hits
c
is it perhaps a difference between x86 Mac vs M1/M2 (arm64) Mac?
c
we're both using Mac M1 🤔
c
perhaps compare 
./gradlew javaToolChains
and 
./gradlew --version
f
Yes its different https://docs.gradle.com/enterprise/tutorials/task-inputs-comparison/
Copy code
This property may also be set by the "scan.capture-task-input-files" system property. If this is set to any value other than "false", the capture will be enabled. If this is set to "false", the capture will be disabled. If the capture is enabled or disabled via system property, calling this method has no effect. That is, the system property takes precedence over the value set via this method.
👆 1
c
found out that this option was already enabled. File properties improves but the value property (kotlinJavaToolchainProvider) still shows only the cache key
perhaps compare 
./gradlew javaToolChains
and 
./gradlew --version
Same
c
they are the same between each other - are they the same between your Mac and the other dev’s mac (where cache is working)?
c
The minor is different • CI: 
Azul Zulu 11.0.18+10-LTS (amd64)
• Mine: 
Azul Zulu 11.0.19+7-LTS (aarch64)
but until yesterday was 
Azul Zulu 11.0.18+10-LTS (aarch64)
• Other Dev1: 
Azul Zulu 11.0.16.1+1-LTS (aarch64)
• Other Dev2: 
Azul Zulu 11.0.17+8-LTS (aarch64)
-- also w/ cache hit
c
Ok. I don’t know how those combine into the cache key. For our projects we use this in gradle.properties such that local installs of JVMs aren’t considered for consistency with CI builds
Copy code
# force standard provisioning of JDKs for toolchain tasks (separate from JVM that Gradle uses)
org.gradle.java.installations.auto-detect=false
…even if that helps its a band-aid, need to understand what goes into that cache key and how to normalize it.
👍 1
This may help:
If you want information about the build cache key and individual input property hashes, use `-Dorg.gradle.caching.debug=true`:
https://docs.gradle.org/current/userguide/build_cache_debugging.html#helpful_data_for_diagnosing_a_cache_miss
c
Thanks! I tried the 
org.gradle.java.installations.auto-detect=false
but it didn't make difference. I'm using the caching.debug flag too. The information is similar that the GE shows 🙁
c
what does the debug output show for that task (excluding all the file inputs that we know aren’t the issue)?
c
it shows the input cache key of each input
Copy code
Appending input value fingerprint for 'kotlinJavaToolchainProvider' to build cache key: b618efd0c7d4899a20f3aabf3a4125e9
c
hmmm. not helpful if the actual value used isn’t shown. 🤦
c
yeah 😢
c
it’s possible that the issue is addressed in either Gradle 8.x or perhaps newer Kotlin versions (not sure what Kotlin version is in use).
f
Cesar you are capturing task inputs right? And that has no extra info?
https://gradle.com/enterprise/releases/2022.3/#view-selected-java-toolchains-of-gradle-tasks added better java toolchain support (not sure if the kotlin plugin is supported)
✅ 1
c
Value properties only capture hashes, making it impossible to determine the nature of the change, only that it was that property than changed.
A “value property” is a task input property that is not a file or set of files. Task inputs comparison displays any value inputs whose value changed between the two builds (i.e. unchanged value inputs are not shown). Build scans capture a hash of the value for comparison, not the value itself, so therefore do not show the actual values of the value input in either builds.
c
yep, we're already using toolchains. right now, we kind of managed to read the values instead of the hash using code but we need to dig into the object that generates the kotlinJavaToolchainProvider
c
Is this the toolchain provider in question?
From that the only input property is 
javaVersion
(type: 
JavaVersion
), which is an enumeration of the major java version.
Cesar what does the configuration of that Gradle task look like? (utilitykotlin-util:kaptKotlin)
c
Is this the toolchain provider in question?
We're checking this other class but you're right about the javaVersion
Cesar what does the configuration of that Gradle task look like? (utilitykotlin-util:kaptKotlin)
We use a convention plugin that • applies kotlin • sets the toolchain • sets a few test dependencies (junit.core, kotlin.junit) • set some common code coverage configuration
c
thanks. had a peek at 
DefaultKotlinJavaToolchain
, no additional inputs there. Odd. Is it possible that setting the toolchain has some sort of conditional logic on it?
Is that a 
KaptTask
?
c
compileKotlin
heyy we figured out what was the problem here. Not sure why, but some of my local cached dependencies was somehow "dirty" and influencing in a different input cache key. After I deleted my gradle local cache entirely (not only my project modules cache) it started hitting remote cache
2 Views
Open in Slack
PreviousNext
Powered by