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.

Hey folks, I'm trying to build a React Native app using

./gradlew assembleDebug

, but I keep running into a Gradle failure related to dependency resolution. The error occurs during the

:app:checkDebugAarMetadata

task and says that it can’t find any version of

com.facebook.react:react-native

. Here’s the relevant part of the logs:

> Task :app:checkDebugAarMetadata FAILED

* What went wrong:
Execution failed for task ':app:checkDebugAarMetadata'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
   > Could not find any matches for com.facebook.react:react-native:+ as no versions of com.facebook.react:react-native are available.      
     Searched in the following locations:
       - 
<https://dl.google.com/dl/android/maven2/com/facebook/react/react-native/maven-metadata.xml>
       - <https://repo.maven.apache.org/maven2/com/facebook/react/react-native/maven-metadata.xml>
       - <https://repo.maven.apache.org/maven2/com/facebook/react/react-native/0.71.0-rc.0/react-native-0.71.0-rc.0.pom>
       - <https://www.jitpack.io/com/facebook/react/react-native/maven-metadata.xml>
       - <https://maven.google.com/com/facebook/react/react-native/maven-metadata.xml>
       - file:/path/to/node_modules/react-native/android/com/facebook/react/react-native/maven-metadata.xml
       - file:/path/to/node_modules/jsc-android/dist/com/facebook/react/react-native/maven-metadata.xml

Has anyone faced this before? I'm wondering if this might be related to using

+

in the dependency version or a missing local Maven repo. Appreciate any suggestions! 🙏

For those interested in caching, we are doing a webinar on Gradle Build Caching in July - https://gradle.com/events/gradle-build-cache-07-25/ 🙂

hey folks, does the remote cache takes into consideration which gradle version was used to generate a cache entry? The context is that I'm planning to do a minor upgrade in our gradle wrapper but I'm unsure about the impact on the remote cache once the upgrade has been merged.

set the channel topic: All things relevant to caching. There is also a dedicated #C013WEPGQF9 channel

We’re using aidl which is generating java files w/ comments that have absolute paths. As far as I can see this makes the tasks un-cacheable *between different machines. Is there a way (other than modifying the aidl output and removing the comment) to get gradle to ignore comments when creating a cache key?

Let say I have task that dependent on other tasks. If these tasks succeed but my task fails would the cache of intermediate tasks pushed to cache?

Is it possible to specify a task as cacheable locally only? I’ve noticed that tasks with very small outputs (and generally fast execution) don’t benefit much from cacheing and the RTT to remote is typically negative.

Hi folks. I'm refactoring some custom code generation tasks written by someone who didn't understand task outputs and cacheability. Task A writes to

generated/com/acme/_generated

exclusively. Task B's writes to a dynamic list of output directories like

generated/com/...

and

generated/foo/...

. But when the output contains

generated/com

, we have a conflict with Task A and caching is disabled due to overlapping outputs. What I'd like to do is configure outputs for Task B to say it outputs to

generated/com/... excluding generated/com/acme/_generated

... I doubt this is possible though. Any ideas?

And we have Universal cache (new marketing name as I see it)

Getting back to a topic we discussed here before (@wolfs and others). Context: • https://www.linen.dev/s/gradle-community/t/26748062/i-am-exploring-solutions-for-the-following-scenario-and-look • https://github.com/gradle/gradle/issues/32225 We have a solution in place now for tool installaion that uses

FileSystemAccess

for snapshotting. Last week we noticed that it takes 16m on one developers Windows machine (8m on my AWS Workspace) to do the snapshot of a particular tool. Turns out, the tool consists of 16k files. So this is probably a general Gradle snapshotting question/issue for cases where you have an insane ammout of files: One developer spiked to replace what Gradle is doing with a (simple) custom solution based on what they did in their previous custom build system. It's not really usable as it naively snapshots each file directly and does not make any use of the "snapshot caching" and VFS of Gradle which breaks the UP-TO-DATE case. But what they did is using

Files.walk(rootPath).parallel()...

to process files in parallel, which significantly improved the snapshot creation (first use case) for the 16k files. If I read the Gradle code correctly, files are always processed sequentially (see DirectorySnapshotter). I wonder if there is a particular reason for not using some parallism here. I could not find anything on this topic in the GH issues. I wonder if this ever came up before and if there are any thoughts on this. We are in a situation where it is hard for (certain) developers to understand why the new system is better than the old one if it appears so much slower. It is of course much better in the incremental case, but the "first use" case is what makes a bad impression on some. (I personally also think it is crazy that we have a "tool" consisting of 16k files - but legacy...)