Gradle cache increases by 400 MB every time updating Gradle wrapper version

Description: When updating the Gradle wrapper to a new version (changed gradle-wrapper.properties), then

1. setup-java@v2 first restores the gradle cache from previous run (why??)
2. new Gradle version is downloaded and build
3. then setup-java@v2 creates a new cache file (~800 MB) which is about 400 MB larger than before because it contains two Gradle versions

Changing Gradle wrapper version again increases the cache file size by 400 MB to 1200 MB, and so on…

Here is a run where it happened: https://github.com/JFormDesigner/FlatLaf/runs/4705134891

In “Setup Java 17” the outdated cache is restored (https://github.com/JFormDesigner/FlatLaf/runs/4705134891#step:4:35):

Cache Size: ~425 MB (445413982 B)
/usr/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/19b74bcf-0264-4065-b1ef-448c93c2d4fc/cache.tzst -P -C /home/runner/work/FlatLaf/FlatLaf
Cache restored successfully
Cache restored from key: setup-java-Linux-gradle-707ed6f8250ea8ec2ee660640962308e354fe354d36338715ef1bcab4fcc837f

In “Post Setup Java 17” a new cache with ~836 MB is created (https://github.com/JFormDesigner/FlatLaf/runs/4705134891#step:11:5):

Cache Size: ~836 MB (876885346 B)
Cache saved successfully
Cache saved with the key: setup-java-Linux-gradle-af7e537f7a03362010edc6596ab7fba05bdfb901982028cbd2d21e5291cd932d

Note the different hash keys in the cache file names!

Task version: actions/checkout@v2

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
See above description.

Expected behavior: When changing gradle-wrapper.properties (or build.gradle), then the cache should be not restored.

Actual behavior: Cache is restored even if gradle-wrapper.properties (or build.gradle) changed, which increases the size of the cache file by aboud 400 MB every time a new Gradle wrapper version is used.

[dsame]

I put my suggestion into a PR here to make it more clear what I mean to prevent this problem.

The PR is merged now, and the workaround i’ve suggested in the reply will become unnecessary on next release.

[mandrachek]

@schuenadel - that’s exactly the approach I wound up taking.

@fl250144 - here’s what I used instead of the built-in cache:

  # This works around an issue in setup-java which allows the dependency cache to grow each time the gradle wrapper is upgraded 
 ​      - ​name​: ​Cache Gradle Wrapper and Dependencies 
 ​        ​uses​: ​actions/cache@v3 
 ​        ​with​: 
 ​          ​path​: ​| 
 ​            ~/.gradle/caches 
 ​            ~/.gradle/wrapper 
 ​          ​key​: ​${{ runner.os }}-gradle-cache-${{ hashFiles('**/*.gradle', '**/*.gradle.kts', '**/gradle/wrapper/gradle-wrapper.properties') }}

It adds the hash of gradle-wrapper.properties, so when the gradle version is updated, the cache is rebuilt.

My cache is now back down under a gig.