Results after enabling this in the sample repo: - Last commit before enabling the flag: Home 29 MB. - First execution with the flag: Home 29 MB. - Change a source file: Home 29 MB. - Bump from Gradle 8.4 to 8.5: New home saved with 56 MB. - Bump some dependencies: New home saved with 88 MB. (The dependencies entry, which is separated, grew from 249MB to 255MB, this makes sense, but why does home need to grow here?) - Bump from Gradle 8.5 to 8.6: New home saved with 203 MB. 🤯 - Newer commits: Home remains at 203 MB (is saving new entries, but keeping the size) This is using

gradle-version: current

in the action setup as it's a requirement for the cleanup. But all our builds are using the gradle wrapper defined in the project (this should be fine, but sharing just in case this impacts somehow). After that I've added the debug flag and noticed something that catch my attention in the logs. The Gradle User Home, after extracting common artifacts that the action stores in separate entries, still lists two

transforms-#

folders:

227M    ./caches/transforms-3
493M    ./caches/transforms-4

I don't have much knowledge about these internals of Gradle, but my understanding is that these folders in the cache increment the number whenever the artifacts are not compatible with the new gradle version. So are they still required after a gradle bump?? 🤔

I downloaded the logs generated with the debug flag, which are quite long so no worth sharing here. But this is a summary of all the entries that saved in the cache from the home folder after cleanup. I grouped them by the two main levels and the number of the left is the count of hits from the logs

2 .gradle/.setup-gradle/
   1 .gradle/caches/
 210 .gradle/caches/8.6/
   1 .gradle/caches/jars-9/
   4 .gradle/caches/journal-1/
2422 .gradle/caches/modules-2/
18908 .gradle/caches/transforms-3/
8946 .gradle/caches/transforms-4/
   1 .gradle/notifications/
   2 .gradle/notifications/8.4/
   2 .gradle/notifications/8.5/
   2 .gradle/notifications/8.6/

As you can see, also the notifications folder keeps data from Gradle 8.4 and 8.5 even if we are running Gradle 8.6. The contents on this folder are insignificant, but I think they prove that some legacy data still remains in the cache.

The

gradle-home-cache-cleanup

support relies entirely on Gradle's built-in cleanup mechanism, but the action will touch certain files and "age" certain other to force the cleanup to run more frequently.

For this reason, I'm entirely unsurprised that the

notifications

directories remain in place. Gradle doesn't do any cleanup of these files.

Can you please raise an issue at https://github.com/gradle/actions with what you're seeing? A few things I can note at this time: • Instead of using

gradle-version: current

in your action, it would be preferable to code the same version that is used in your project. Fewer Gradle versions being used means retaining fewer files. • When you enable cache debug logging, the most interesting messages will be found in the "post-action step". Search for

Gradle User Home (directories >5M): after extracting common artifacts

and you'll see the main directories that are contributing to the Gradle User Home cache entry size. It would be very interesting to see if these grow over time, or only when updating to a new Gradle version.

I've just tried something else: We just removed all the cache entries, so the runner started with an empty cache. This is the main repo (the one whose home cached entry was

3.6 gb

and was reduced to

2.3 gb

after enabling the cleanup three days ago). The new entry for the home is just

457 MB

. Then these builds only produce/require 500mb. So there is a lot of legacy data that is being preserved from one run to the other that is not properly captured by the cleanup mechanism. 👀 Some other data for context: • We started using Github Actions 4 months ago, with the gradle action already integrated. We never looked into the caches it was producing until now. • 3 months ago the home cache had

1 gb

(eldest data I could find) • It was using Gradle 8.4 then. We bumped to 8.5 couple of months ago. And to Gradle 8.6 two weeks ago. • Besides Gradle version, something else must contribute to this increase, as we see a constant increase week over week, even without bumping gradle. But many engineers contribute to this repo, so is not a controlled environment and is hard to point what causes these increases. • Cleanup was enabled three days ago. First screenshot: Last commit that used the already existing cache (Gradle User Home size: 2367 MB) Second screenshot: First commit without cache (Gradle User Home size: 456 MB)

In any case, I will raise this issue in the GH gradle actions repo later with the most relevant info from these messages. I also will keep a close eye in the next Gradle bumps and report back if we see a significant increment. 🙂

Raised, thank you for your support @Daz DeBoer! 🙌 Feel free to reach out if you need other details :)