Bad cache keys generated; results in 0 remote cache hits

Help/Discuss
1

Sorry to post again, but I think my previous post did not accurately summarize the issue I’m having.
(is there no way to delete an old post?)

We have deployed the Docker image gradle/build-cache-node and have it up and running. Our CircleCI is populating the cache, and we see the cache building up. So far, so good.

Co-workers who check out a branch and run assembleGoogleDebug see great time savings. The remote cache is being hit consistently, which we can verify by the logs and quick build time.

However, I cannot get any cache to pull from remote; remote cache hits are consistently ZERO.
Every attempt is met with an error like:
Response for GET https://<REDACTED>/cache/dcbab2c8ac0736f61f5e9eefc2896f61: HTTP/1.1 404 Not Found

I checked “caching relocation” on my local system and it worked great. A local cache built in clean directory A assists the clean build in clean directory B (as described in troubleshooting methodology) as expected

My co-worker and I both checked out the exact same commit from our develop branch (continually integrated by CircleCI and generated a Gradle cache). His build finds and uses the remote cache, and mine does not.

In checking our debug build logs, we see that the cache keys he generates are different than mine. There must be something configured in my local machine that keeps my keys consistent for local cache tests, but is incompatible with the remote server (and, by extension, my co-workers)?

I’ve spent days looking into this and I’m at a complete loss on how to proceed. How can I ensure that I’m generating proper cache keys that will be compatible with my remote server?

We are both on macOS Monterey 12.2, running Gradle 7.2.

2

Do you use a different Java major version?
Do your sources have other line endings, e. g. by different Git settings?
Can you use build scans to see what input has a different fingerprint, that might give a clue?

is there no way to delete an old post?

Afair, just delete the actual post and the thread should go away too.

3

I see no edit button or delete button. Maybe I have to “earn” the right to do that in the forums? :person_shrugging:

At any rate, thank you for your ideas. I’m quite new to this process, so I’ll look into your suggestions. The Java major version may very well be different. Line endings shouldn’t be an issue, I think. This is two macOS laptops running the exact same version of macOS, checking out the exact same version of the code base from the same source. Line ending changes would manifest in other problems as well, such as when checking in code to git (line endings should change and be flagged as such, I would think?).

what input has a different fingerprint
I’ll see what I can do to understand that, thank you.

5

JVM version difference was the key to this problem.
Thank you very much for pointing me toward that solution.

1 Like
6

I see no edit button or delete button. Maybe I have to “earn” the right to do that in the forums?

Ah, yeah, right.
At trust level 0 you can only edit your own posts for 24 hours if Discourse runs on default settings.
If you reach trust level 1, you should be able to: Understanding Discourse Trust Levels