bigdaz
commented
1 month ago As far as I can see, this is working as expected.
- Each Job will have save and restore it's own Gradle User Home cache entry: the only time that
build-secondwill start with a cache entry frombuild-firstis in the case that there's no cache entry from a previousbuild-secondrun. The Gradle User Home cache entry then references all of the other entries (dependencies, wrapper-zips, etc) - If the jobs use exactly the same set of dependencies, then the Gradle User Home Cache entries will reference the same
gradle-dependencies-v1-*entry: this entry will be shared. But since the builds use different dependencies, they have separate dependency entries. Unfortunately if there is overlap between the sets of dependencies for different Jobs this results in some duplication of storage. (** see below) - The contents of
gradle-generated-gradle-jars-*andgradle-wrapper-zips-*entries are identical between the Jobs, so the Gradle User Home entries reference the exact same sub-entries: these sub-entries are shared between the jobs. So there is no duplication in the cache storage of this content.
Note that when you re-run a Job, it doesn't get a new git SHA and thus you don't get a new cache key for Gradle User Home. This is why you see the "Entry not saved: referencing 'Gradle User Home' cache entry not saved". To test this properly, you'll need to push a dummy commit for each run.
Please check out https://github.com/gradle/actions/blob/main/docs/setup-gradle.md#how-gradle-user-home-caching-works for more details on how this works.
** There are definitely ways this could be made more efficient, if we either stored one big entry with all of the dependencies for all of the jobs, or by extracting the common dependencies into one entry and only storing the unique dependencies per-job.
cloudshiftchris
aSemy
Repro: https://github.com/cloudshiftinc/gradle-setup-action-cache-repro/actions/runs/10067337462
That repository consists of a small "Hello World" Gradle / Kotlin project, with two build files: 1) Build with Kotlin 1.8.22; 2) Build with Kotlin 1.9.25;
There's a GHA workflow that runs two steps, sequentially, using each of the above build files. Each step checks out the code, calls
setup-gradle(v4 beta 1), and executes the respective Gradle build file (build.gradle.kts or build-second.gradle.kts).The second build "cleans up" artifacts it didn't use from the first build:
This isn't desirable in a multi-step setup - we'd want to retain all the cached entries and only cleanup at the end.
For reasons I don't currently understand the cache isn't updated after the cleanup in the second build, even though the cleanup removed entries:
The issue starts here where
setup-actionstores the current timestamp, and then in the post-build cleanup removes everything older than that. This assumes a closed-loop where it's a self-contained build, which doesn't work for shared caches (dependencies, wrappers, etc) that other builds will use/update/cleanup.Not sure what the best solution may be - perhaps loosen the cleanup windows to "older than a day"; not thrilled about making it configurable, as one wouldn't know what to reasonably put (is 10m too long? what if the execution time varies? and so on).
If there's a way to get the "start of the workflow" timestamp that may be more deterministic, though that still leaves holes where there are different workflows running that share those caches - one may wish to save the shared caches for longer periods (e.g. workflows that use those caches that run weekly, for example).