Improving gradle-home-cache-cleanup detection of unused files

[rolgalan]

Hi! 👋

Our Gradle home cache is getting so big in our project that is taking long times loading and storing the cache, so we enabled the gradle-home-cache-cleanup flag to remove unused files from Gradle User Home before saving to the cache.

After enabling this flag, the home cache entry dropped from 3.6 GB to 2.3 GB. While this is an improvement, we expected more. If we remove all the caches in Github actions and we start a fresh new runner without any cache, it only generates 457 MB. Therefore it is still keeping 80% of data that was actually not used in the last build. Please note that I only refer to the Gradle User Home entry.

After doing some debugging in a sample project (by enabling logging and exploring the sectionGradle User Home (directories >5M): after extracting common artifacts) I observed that it keeps multiple transforms-x folders, which represent a big part of the contents stored in the home cache. In theory a certain version of Gradle should use a consistent X value for that folder, so most likely the cleanup is not properly removing these unused folders left behind after a Gradle bump.

This is an Android project, mostly Kotlin code. The cache was never cleaned up in the last 4 months. It started with Gradle 8.4, later we migrated to 8.5 and last week to 8.6.

I also observed the home increasing significantly when bumping some dependencies (please note that I do not refer to the dependencies entry, which is stored separately, but still talking about the home), but I didn't research this thoroughly. Most likely this could be the next step to explore after figuring out why the transforms folder is still there.

You can check the thread in the slack community for a few other details.

Thanks!

[bigdaz]

Thanks for the report @rolgalan . I've done some investigation, and it seems that Gradle does not cleanup the unused transforms-3 directory when running builds with Gradle 8.6.
This will need to be fixed in Gradle before we can fix the behaviour in this action.

I've raised gradle/gradle#28178 for this issue.

[bigdaz]

FYI this has been fixed in Gradle and once v8.8 is released we can incorporate the fix into this action.