I've successfully configured a remote build cache node for Kotest, and it works wonderfully. However, the GitHub Action cache is still incredibly overloaded. Build Cache is disabled local cache on CI, as is recommended in the Build Cache docs. Is there something I've missed, or something more than can be done?

Hi, how to rerun artifact transform? i want to test my artifact transform cache performance, but it always up-to-date. Use --rerun-tasks or clean not invalidate artifact transform cache

A difference in KSP task

classpathStructure

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?

If a task (like KSP does for example) manages their own internal caches, how should such a directory be marked in Gradle? KSP today marks it as

Internal

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 work

I have two large Android projects: ProjectA, which uses Gradle 8.3, and ProjectB, which uses Gradle 8.8. When switching between these projects in Android Studio, we often encounter build issues. These are typically resolved by rebooting the machine and clearing the

$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?

Gradle Build Cache Node 20.0 appears in the release history but not among the listed JAR downloads. Is that intended? See https://docs.gradle.com/build-cache-node/#version_history whereas GET https://docs.gradle.com/build-cache-node/jar/build-cache-node-20.0.jar currently encounters 404.

Does Intellij / Android Studio not use Gradle's dependency cache? It seems like when I sync the IDE it downloads all of the artifacts again even if: 1. Already downloaded those artifacts when building with Gradle on the command line before that 2. Another project already downloaded those artifacts I've been noticing this with Jetbrain's Compose since there are a ton of artifacts, and their Maven repo is relatively slow.

Hi. I just downloaded android studio and when creating a project I immediately got an error C:\Users\user\.gradle\caches\transforms-4\30875eea6872baddd3705431d8e2737f-6fd2de91-e04f-415c-9b14-fc947f2e9a89 -> C:\Users\user\.gradle\caches\transforms-4\30875eea6872baddd3705431d8e2737f. How can I fix it? I've already tried everything(

Hello! I'm facing a strange caching scenario: I have an Android module which 74 other modules depends on it. When I make an ABI change (add a parameter to a public function to an interface) in this module, it recompiles 71 modules. But, only one module really depends on this interface I just changed, so I expected that compile avoidance played its part. Am I missing something? More details on the 🧵

Hey folks, Is there any documentation on how does changes in jvm version impact caching? I understand a change in major version will cause a re-execution of tasks..but what about minor version changes or name/vendor changes?

Hey all. Just want to confirm my understanding of these two gradle flags around caching: • --no-build-cache -> Does not pull from or push to the gradle cache • --rerun-tasks -> Does not pull from the gradle cache, but will push

(yes it's probably not that simple, but high level)

how do you play around the classpath cache key of a task? I'm investigating performance issue and I'd like to know what makes it divergent between builds Is there a way to generate it manually?

Hi all! I’m having trouble with configuration cache and environment variables. When updating an environment variable the application gets the previous value if configuration cache is reused. If I start with

--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.

Can someone help me understand under what circumstance will this occur. I seem to be getting a cache miss because of this:

I have question regarding configuration cache. I want to execute task only when other task is execute without configuration-cache i just use

onlyIf(task.project.tasks.getByName('compileJava').state.skipped)

Going over academy - could it remember my play speed settings for all videos?

And question about caching setting

removeUnusedEntriesAfterDays

- 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.

I am exploring solutions for the following scenario and looking for feedback/thoughts/ideas. I need to download and extract tools from a repository (zip or 7z). Sometimes these are huge (1gb+) and thus performance and not wasting disc space (by having the same tool extracted multiple times in different locations) is quite important. Currently, the repository may be a folder (on a shared drive). This is because we are transitioning a large legacy setup to a Gradle-based solution. Therefore, we also need to support a few ugly things for the time being. Our current solution is based on standard Dependency Management. The folder on the drive is modeled as ivy repository with custom layout. The downloading-only-once and caching of the Zip files work well for us. What gives me trouble is the extraction step. Right now we use an Artifact Transform but it is not working out for the following reasons: • (1) The transform implementation is part of the custom plugin classpath. Therefore, each time we change something else in our plugins, the transform is outdated. The transform itself has not been touched for months. Right now, as things are under heavy development, this happens daily. Initially I thought we can accept this, as at some point there will be releases that are used for longer. But given the sheer size of all the things that are extracted, even that is problematic. • There are a few requirements for legacy reasons that we cannot get rid of in the transition phase we are in right now: ◦ (2) Some tools need to be placed into a specific destination location. This is bad, and eventually should not happen anymore. But legacy... we cannot change everything at once ◦ (3) Some tools are more like large systems. When running, they modify something in their own installation directory. This is also not right, but we need to support this for some selected older tools for now. In the previous build system, users were able to define which files of a tool should be excluded when doing checksum checks. If it was not for (1), I would consider doing something hacky/nasty/imperformant to support the legacy requirements. But all this together let me to the conclusion that we should explore alternative solutions to Artifact Transforms. I am currently thinking about using a Task to do the extraction. As we basically use custom tasks for everything, it would not be too difficult to register and wire one Task per tool instead of the Transform. However, relying only on the standard UP-TO-DATE mechanism would not solve issue (1) and (2). (Although (2) could maybe be solved with some kind of filtering when defining the outputs of the task.) Solution: I am thinking to have a kind of "2nd-level" checking in the task action. Similar to what

@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?

build-cache-node 20.1 release misses notes https://docs.gradle.com/build-cache-node/#version_history Would this be a right channel to report such issue visible to maintainers?

Is there any specific reason why I don’t need to save on CI

gc.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.

Hey. Are there any existing functions for combining multiple `ValueSource`s? Let's say one of them reads value "A" and the other reads "B", which can change independently from each other, but I'm interested in their combination e.g. "A+B" Can this be declared with the existing API without `get()`ting the values, similarly to how

map()

works, which returns another

Provider

?

How do I best address the Develocity warning

The 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?

Hi 👋 I'm trying to reuse Gradle remote cache across different clients but facing an issue that most of all build cache key are different between remote machine and locale machine. I'm able to see what Value properties are different between remote and local in Develocity. But can't confirm the actual value inside of the value property. Is there any way to confirm what value is inside? This making me so difficult to debug.

👋 hi! I’m looking for a way to understand clock-time difference of build duration between builds that use remote build cache and those that don’t. I understand that when browsing Build Scan I can read the sum of avoidances of each task, but they of course don’t take parallelization into account. E.g. I have this scan which was a clean build (removed local build cache, and

build

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?

Hey folks, I am trying to re-implement what actions/setup-gradle does but with GCP buckets, and am noticing that when I cache the following folders within

~/.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

.

Does anyone have any idea why I get an "Overlapping outputs" problem for a task that should not have it, but only on GitHub Actions? This is the run on GHA: https://ge.spockframework.org/s/vnf6tebn2ygd4/timeline?details=3yt6nuz2vwgza This is the local run: https://ge.spockframework.org/s/y6x7rzl55yags/timeline?details=3yt6nuz2vwgza Both on the same commit, both with the same task started. Locally the task can be cached perfectly fine, on GHA it complains about overlapping outputs. I even added this debug code:

allprojects { 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.

Im trying to tell Gradle to clean up any cache keys that were not part of the active run. My understanding is I can put something like this into `~/.gradle/init.d/cache-settings.gradle.kts`:

beforeSettings {
    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.

Hello, we am trying to share gradle cache among different devcontainers with vscode for our local development. We initially encountered the journal lock issue when different devcontainer mounts to the same ~/.gradle/caches folder and today our workaround is to have cache on individual devcontainer. We are using gradle version 8.13 and with gradle for java extension https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-gradle. I wonder if this is an issue on vscode extension or sharing gradle cache among different containers. Not sure if this is the right place for this enquiry but let me know if any information needed. Thanks!

Tried to search, but failed. What is reason for configuration cache not to be reused when I see next message

Calculating task graph as configuration cache cannot be reused because a build logic input of type 'ProcessResultValueSource' has changed.