gradle-dependencies-cache should take job-id into account

[iNikem]

Currently there is no easy way to customize cache key for gradle dependencies cache. In my case I have a big multi-module gradle project which has two different types of GHA jobs: one exercise the majority of modules and another only a small subset of them. They use a vastly different gradle dependencies with almost 0 overlap. Unfortunately in both cases the cache key calculated is the same. So these jobs effectively overwrite each other caches making them totally useless.

If gradle dependency cache used job-id as part of the cache, this problem would be solved.

[anuraaga]

@iNikem This is funnily the opposite of my #25 :)

In our huge build, I think the dependencies cache might be in the gigabytes

dependencies-gradle: uploading 2043 MiB, 12752 files as 1-delta-dependencies-gradle-Linux-defaultbranch-66d4d090fa8f834ebc9893e4e179ca7d81c7ca72

If so, we'll easily run over GitHub's cache size limit if each of our job-id's had a separate cache.

I think the correct answer is for us to set gradle-dependencies-cache-key: in a way that allows there to be only two cache keys for dependencies, but not one for each JDK version.

[anuraaga]

46 is related

[iNikem]

Ok, true. Just using job-id to separate dependencies cache is indeed a bad idea. #46 it is then.