Can anyone tell me if I’m reading this correctly. I’m debugging why a task is not hitting the remote build cache and I’ve come across this discrepancy in the cache debug output. On my local machine

Appending input file fingerprints for 'inputArtifact' to build cache key: 3447d06a1cf0b5b0770a5a19c48d6c16 - NAME_ONLY{/Users/justinbreitfeller/.gradle/caches/modules-2/files-2.1/com.android.tools.build/aapt2/7.3.1-8691043/318150c1078be0bd4bdff348e6d79b8ab7991653/aapt2-7.3.1-8691043-osx.jar='aapt2-7.3.1-8691043-osx.jar' / 4341034cb2e00bae6db6d9e642ab5c12}

On my remote machine

Appending input file fingerprints for 'inputArtifact' to build cache key: 0df6c43612fd0d3d6d0860576053d155 - NAME_ONLY{/home/circleci/.gradle/caches/modules-2/files-2.1/com.android.tools.build/aapt2/7.3.1-8691043/41177c11a257af096624e80d433714aae61ca9f6/aapt2-7.3.1-8691043-linux.jar='aapt2-7.3.1-8691043-linux.jar' / 25f9626e6fddbffaa42760fb2c950d38}

Am I wrong to assume that this NAME_ONLY inputArtifact won’t help cross platform since the JAR files have the platform in its name?

Is this expected if we make abi changes, then all module depend to it will resulting different cache key ? for example when printing task input it saying that classes.jar is different.

Is it possible to configure Gradle to push to both local and remote build cache? If I enable both caches and enable pushing to remote cache, Gradle never seems to push to remote cache.

👋 How can I debug

Class path of task '...' has changed from xxx to yyy

? I see it happen for modules with very few dependencies when I change a completely unrelated

build.gradle

file (one that the offending module doesn’t depend on). Build scan doesn’t seem too helpful here sadly

Hi folks, may I know how to deal with the

inputChanges.getFileChanges(...)

with

ListProperty<Directory>

? Should I convert it to

ConfigurableFileCollection

or is there any other ways can help me keep the

ListProperty<Directory>

property type which is more clear to be used? According to the doc:

…be it of type

RegularFileProperty

,

DirectoryProperty

or

ConfigurableFileCollection

Hi all - not sure if this is the right place to ask this - but I'm recently getting an error in IntelliJ while building related to gradle caches. The root cause is my company compliance app is blocking a log4j file due to it being flagged as vulnerable, and this file is sitting in the gradle source here: https://github.com/gradle/gradle/tree/master/subprojects/docs/src/snippets/antMigration/fileDeps/groovy/libs Its odd that I'm only seeing this problem inside intelliJ, and not on the command line, was wondering if anyone had any insight into a workaround for this. I can report this issue in github and hopefully the offending file will be patched but its blocking some of our developers already.

org.gradle.internal.execution.OutputSnapshotter$OutputFileSnapshottingException: Cannot snapshot output property 'outputDirectory'.
java.io.UncheckedIOException: Failed to create MD5 hash for file '/Users/spence/.gradle/caches/transforms-3/b857c89a93e3ad26d7a3a2df48b5cb23/transformed/unzipped-distribution/gradle-7.5.1/subprojects/docs/src/snippets/antMigration/fileDeps/kotlin/libs/log4j-1.2.8.jar' as it does not exist.

I’d like to add some testing around remote and local cache hits. Does Gradle support this in any way?

Hi folks, I have a system property that is changing on every branch, which appears to be breaking the cache for test tasks. I have read through the docs here on property file normalization, but it doesn’t include anything about ignoring system properties. Is there a way to do it?

Hi, How do we check why task artefact size increase? I just realize my artefact size increased 20% recently, but not sure which update/changes causing it. any advice ?

Hello! I recently started using Gradle build-cache which significantly improved clean build time (6 times faster). Unfortunately, benchmarking using gradle-profiler pointed out slight regression on incremental builds (~20% slower). Is it intended behavior? I cannot find anything about that on the internet, but from the logical point of view, it makes sense (cache overhead is probably non-zero). I'm also wondering why this flag is not enabled by default, are there any cons to using that?

Would using Oracle Java 17 on CI (that populates remote cache) and OpenJDK 17 locally cause cache misses?

Hello! I am setting up a remote build cache for our project, and I was wondering, is it beneficial to disable the local build cache on the CI, or is it better to keep it enabled? I've seen several examples online with it disabled, but no guidance in the documentation. Thanks!

Hi! I have another question related to remove build caches. Now that I have it set up, I was looking into the gains for our Android project, and I noticed that on an M1 MacBook I am always getting 0 remote cache hits, whereas on an Intel MacBook I am getting many hits. The CI that pushes to the remote cache is an x86 one, is the different architecture an issue? Are there any workarounds, other than having another CI build in parallel that uses an ARM execution environment?

Why my

build cache overhead

shows 2hrs - it took only max 45 minutes after running these commands • rm -rf ~/.gradle/cache/build-cache-* • ./gradlew clean • ./gradlew assembleDebug

Hi! I have an android project that run on Travis and I found that we’re uploading every time the caches because files on modules-2/files-2.1 like androidx libraries are marked as changed. Could something impact that libraries .pom or .aar and changed them everytime?

Hello, I have a Tar task which is attached below. Using

-Dorg.gradle.caching.debug=true

I can see that two invocations of the task are processing the same files, each with an identical fingerprint between executions. However,

Appending input file fingerprints for '$1' to build cache key

still outputs a different fingerprint per execution. Any idea how I can debug this further? The tarred file paths are not considered for fingerprinting right? I can attach the logs as well, though they might be largish. Thanks Tar task:

task srcTar(type: Tar) {
    inputs.files(project.fileTree(".") {
        include "src/main/**"
    })
    outputs.file(includesTarFile)
    outputs.cacheIf { true }
    from projectDir
    getArchiveFileName().set(tarArchiveFileName)
    include "src/**/*"
}

(Gradle 7.6).

Hi 👋. I have a

build-logic-settings

included build in my

pluginManagement

block and I have a convention plugin to configure the build cache inside the project, as I understand from the docs

This configuration precedence does not apply to plugin builds included through pluginManagement as these are loaded before the cache configuration itself.

cache config wont work for

build-logic-settings

, so as a workaround I've applied that plugin directly in

build-logic-settings

apply(from = "cache-plugin/src/main/kotlin/convention-cache.settings.gradle.kts")

but after generating a build scan it says that

The build cache configuration of the root build differs from the build cache configuration of the early evaluated ':build-logic-settings' included build

so what's the right way to have the same build cache config?

Is there any way to configure the remote cache with

gradleEnterprise.buildCache

remote(gradleEnterprise.buildCache) {
  isEnabled = true
   isPush = isCI
}

in the included build that is inside

pluginManagement

block? I've tried copy-pasting the same config in my included build but got this error

A problem occurred configuring project ':build-logic-settings'.
 Could not create service of type BuildCacheController using .createBuildCacheController().
java.lang.UnsupportedOperationException (no error message)

HI all, What are the opinions on activating remote cache for devs to pull from (not push to) with respect to tests. We have recently proposed to activate this but are having some concerns raised internally specifically around test tasks. One developer stating they had used this functionality previously elsewhere but it caused frustration as "people were trying to debug their JUnit tests ,and wondering why they were completing immediately without stopping at any breakpoints?" on the surface this seems like a valid concern / use case, if im trying to debug a unit test in IntelliJ but the test is never triggered as its skipped due to cache hits from remote. Is there a recommendation around this use case?

Hello! I have a problem understanding why sometimes i see "Fingerprinting inputs" stage of FROM-CACHE task duration as like 0.5s and sometimes 55s. (build scan info) It's the same task, android gradle plugin's

com.android.build.gradle.internal.tasks.DexMergingTask

It's incremental, but i thought it shouldn't affect fingerprinting. How to debug it further?

hello, would anyone know how to get “remote cache hit ratio” for all/range of builds via either export api/enterprise api? context: I’m troubleshooting an issue where I see 0 remote cache hits between local machines (m1 mac) and remote cache (linux). I was initially thinking I’ve caused the issue by moving our convention plugins from binary dependency to composite build, but then a random sample of local build scans from other devs (without my changes) also show 0 remote build hits so… I need to dig deeper 🐿

one more extra question: is it normal to expect that using composite-builds for convention plugins should have remote and local caches working just fine (on android projects), or is that a known issue?

How do you think I could implement caching correctly? I have some files downloaded from the server during build time. I set input the url. And caching works fine. How to add a “force” flag that will ignore the cached downloaded files and redownload them again?

Is anyone experiencing this error with the Build Node Cache? We've just updated to version 14.0 and we've been encountering these errors quite frequently.

Could not load entry d6d33e5606c65e111f4e29d41ec49a57 from remote build cache: Premature end of Content-Length delimited message body (expected: 12,061,751; received: 1,543,568)

What could cause a cache miss by "Task implementation changed" between two builds that have the same dependencies?

Hello, I am seeing worrying issue in some of our team's build scans: kaptKotlin tasks are not cacheable, because

Overlapping outputs: Gradle does not know how file 'build/roomSchemas/kaptDebugKotlin' was created (output property 'annotationProcessorOptionProviders.$0.$1.effectiveSchemaLocationDir'). Task output caching requires exclusive access to output paths to guarantee correctness (i.e. multiple tasks are not allowed to produce output in the same location).

It's certainly doesn't affect every build, so I can't understand the reproducing steps for now. I ask here, hoping it's some known issue with known workaround. Versions: • AGP 7.4.1 • Gradle: 7.5.1 • Cache fix plugin: 2.6.5

Hi, I'm using org.jetbrains.dokka plugin to generate kdoc on a kotlin project, the pluign has a property

moduleVersion

which gets set under the hood at build time it seems, this is set to the Gradle project version by default, for us that changes run to run based on a timestamp (removing the timestamp is not a option right now in our versioning schema). This moduleVersion property which dokka sets is breaking caching for us as input value "moduleVersion" is different from run to run, due to our versioning timestamp, Any examples on how i can normalize this to tell Gradle to not consider this with caching, from some googling possibly i can use this interface ?, but having trouble finding any actual examples of use.

hey, cache team! Do you plan to support caching of failures? In my case I have tasks which are validation tasks, e.g check that a release doesn't depend on snapshots. For a given set of inputs, the task will always fail if validation is supposed to fail, so it's worthless to re-execute the task, it should simply rethrow the same exception.

When disabling caching for a task, is there a way to disable only pulling from cache, but not storing? Use case is to disable caching for tasks not worth pulling from cache in CI, but still have CI store them in cache so that developers can benefit from it. Currently, we do

cacheIf { !isCI }

but that means developers will have to build it locally, which may or may not be an issue