setup-java: Gradle cache increases by 400 MB every time updating Gradle wrapper version

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.

@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.

Hello @DevCharly

It seems i found the root cause and can suggest at least the workaround which can be called a solution as well.

The origin of the problem is the logic of actions/cache restore: it DO restores the most recent cache even if the cache-key was not found.

As a result, despite gradle/wrapper/gradle-wrapper.properties has been changed to the new version of the gradle and cash-key has changed the old cache with the previous gradle still restored and new gradle jar with the dependencies files does not replace the old one, but is added to the .gradle/cache folder.

Thus, to resolve the problem it is necessary either 1) changes the logic of actions/setup or 2) add a cleaning step to actions/java-setup

My opinion is: neither of above can be applied because of 1) is breaking change and 2) is not flexible enough

I’d suggest to add the project specific step to the pipeline, something like:

        - uses: actions/setup-java@v3
          id: setup-java
          with:
            java-version: '8'
            distribution: 'zulu'

        - name: Force clear gradle cache
          if: steps.setup-java.outputs.cache-hit != 'true'
          run: rm -r ~/.gradle/caches

This way completely solves the issue but leaves an ability to fine tuning the specific build. Any thoughts?

Is this why my cache is now 3GB in size, actions/setup-java@v3 takes ~12 minutes to run (downloading and restoring the cache), and why my post run setup-java action is failing?

Is there some way to purge the cache and get a clean slate at least for the time being?

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

Shouldn’t the cache ID calculated from the (gradle) files in working directory, which was previously checked out from git?

It is, but when no cache with that id is found, like when you run the first time with a new dependency configuration, it falls back to a cache from a previous run. That fallback is defined with the restoreKeys parameter, which I suggested above to remove.

But on the other hand that means for every change all(!) dependencies are downloaded again.

Isn’t this the expected behavior?

One could argue that when you change only one small dependency out of many others it may be more efficient to keep 2 versions of that in the cache instead of downloading all again. But as you said, when the cache never becomes dirty I would also prefer to start over with a completely empty cache whenever something changes.

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

I think so too, especially if there is not other cache eviction happening than this, which would mean it grows “forever” (if you access it once a week). My suggestion would be to remove the restoreKeys (3rd) parameter in here, so that whenever the cache key changes you start with a completely clean cache. But on the other hand that means for every change all(!) dependencies are downloaded again.