Sarthak Aggarwal
07/15/2024, 9:25 AMAdam
07/19/2024, 9:13 AMAdam
07/22/2024, 1:56 PMDoni
08/14/2024, 10:30 AMGabriel Feo
08/14/2024, 8:52 PMclasspathStructure
input was found to be the main local-local cache miss in a project. Has anyone encountered this? Any ideas on how to find what the actual difference is between builds?Nicklas Ansman
08/24/2024, 1:38 PMInternal
which isn’t good because when the task output is restored from cache it becomes invalid.
One option is to mark it as LocalState
but that wipes the cache upon cache restoration which maybe isn’t ideal.
It could be marked as an output but it’s also needed as an input (though changes to it should not cause task invalidation so it should not be marked as an input). But is this safe? Obviously whatever is put in there cannot contain absolute path and such for that to workSubodh Nijsure
08/27/2024, 2:30 AM$HOME/.gradle/cache
directories.
Could the difference in Gradle versions be causing these problems, or is there another explanation? Both projects are large, and the time spent waiting for builds to complete when switching between them is significant.
Is there a reliable process we can follow to make switching between projects smoother? Are there any best practices we should adopt?Ken Shackleton
08/27/2024, 7:53 PMEli Graber
09/10/2024, 5:25 PMВадим Акст
09/14/2024, 7:36 AMGuilherme Lima Pereira
09/23/2024, 6:40 PMSatyarth Sampath
09/25/2024, 3:31 AMMatthew Inger
09/25/2024, 5:28 PMMatthew Inger
09/25/2024, 5:28 PMGiuseppe Barbieri
09/26/2024, 10:02 AMArve Seljebu
10/03/2024, 7:35 PM--no-configuration-cache
, the application gets the updated value.
It’s reproducable from shell and IntelliJ and on other peoples machines, but not in a minimal viable example.
Example in shell
export SOME_ENV=a_value
./gradlew :project:run
# ctrl + c
export SOME_ENV=new_value
./gradlew :project:run # application gets SOME_ENV == a_value, both from System.getEnv and ktor environment.config.peroperty (HOCON)
In IntelliJ I edit environment variables in run-configuration and start. Same behaviour.
Can mention that when using debug mode in IntelliJ, it does break at a break-point in buildSrc when configuration cache is reused. But if I add --no-configuration-cache
to the run-configuration, it breaks every time.
Have tried -Dorg.gradle.caching.debug=true
, but could not see anything interesting.Nikolay
10/07/2024, 8:59 PMDavid Ignjić
12/04/2024, 12:37 PMonlyIf(task.project.tasks.getByName('compileJava').state.skipped)
Eug
12/06/2024, 5:19 PMEug
12/06/2024, 5:28 PMremoveUnusedEntriesAfterDays
- let's say I have library that not often updated, that means cache is removed after specified days and it will be missed on the next run. I wonder if for different projects we could set a different removal number of days.Jendrik Johannes
12/12/2024, 11:17 AM@Incremental
tasks do:
• When the task first runs, I store a hash of the output somewhere
◦ Here I may also do some filtering if required for selected tools to cater for (3)
• Before I actually extract the Zip, I hash the existing output folder and check if the hash has changed. Only when it changed I clear the output and re-extract.
My question:
• I am hoping to reuse an existing Gradle Service for the solution I sketched – even though it is internal API. I am looking at ChecksumService
, but that's for single files. Is there something I can use out-of-the-box to process the whole destination directory? @wolfs maybe you have a pointer for me?
• Any alternative ideas?Sergii Pechenizkyi
01/15/2025, 11:27 AMНиколай Клебан
01/28/2025, 10:06 PMgc.properties
as mentioned there.
I want to be able to give ability to my jobs cleanup cache from time to time and as far as I understand - gc.properties
is a part that makes it possible.Andrzej Zabost
02/24/2025, 2:53 PMmap()
works, which returns another Provider
?Jendrik Johannes
02/26/2025, 7:34 AMThe build cache configuration of the root build differs from the build cache configuration of the early evaluated ':plugins' included build. It is recommended to keep them consistent, see here.
when using
pluginManagement {
includeBuild("gradle/plugins")
}
On the documentation page it only say:
> NOTE: This configuration precedence does not apply to plugin builds included through pluginManagement
as these are loaded before the cache configuration itself.
But not what I can do. Should I duplicate the build cache configuration? E.g. in these two places:
• gradle/plugins/setting.gradle.kts
• gradle/plugins/src/main/kotlin/build-cache.setting.gradle.kts
(to be applied in settings.gradle.kts in roo)
Or is there another/better solution?Kentaro Doi
03/07/2025, 7:24 AMWojciech Zięba
03/26/2025, 10:37 AMbuild
directories) so it took everything from remote build cache (except 1 task). It lasted 2m 3s. From my local experiments I know that clean build without remote build cache takes around 3m. Sum of avoidances is 14m 49s, but is there a way to get the clock-time difference of build (~1m) from build scan?Rohit Krishnan
04/24/2025, 9:01 PM~/.gradle/cache
, it ends up skipping tests when running ./gradlew testDevDebugUnitTest
for an Android project (even though I did make changes to one of the gradle modules). The folders i'm caching are 8.10.2
, build-cache-1
, jars-9
, and modules-2
. Is this the expected behavior when caching this across runs on Github? (It's the same task and the same CI runner).
Looking at logs, it says Task :features:nameOfFeature:testDevDebugUnitTest FROM-CACHE
.Vampire
04/30/2025, 3:10 PMallprojects { tasks.all {} }
tasks.register('foo') {
doLast {
allprojects*.tasks*.all { task ->
outputs.files.files.findAll { it.absolutePath.contains('.github') }.each {
println("FOO: ${task.name} | ${it.absolutePath}")
}
}
}
}
And the result even for the GHA run is exactly as expected: https://ge.spockframework.org/s/vnf6tebn2ygd4/console-log?page=1#L100
No overlap with any output of any other task in the whole build.Rohit Krishnan
05/01/2025, 12:53 AMbeforeSettings {
caches {
releasedWrappers.setRemoveUnusedEntriesAfterDays(45)
snapshotWrappers.setRemoveUnusedEntriesAfterDays(10)
downloadedResources.setRemoveUnusedEntriesAfterDays(45)
createdResources.setRemoveUnusedEntriesAfterDays(10)
buildCache.setRemoveUnusedEntriesAfterDays(5)
}
}
However when I set those values to 0
days (so I can clean up anything before the current session), it errors saying I should use the setRemoveUnusedEntriesOlderThan
API. Is there any example or documentation on using this new method? It doesn't seem to resolve in my 8.10.2 version of Gradle.