Cache cleanup fails when run with Gradle 8.11

[bigdaz]

Gradle 8.11 changes the (internal) cache-control API we are dependent on. We need to adapt to this change and update so that we use Gradle >= 8.11 for any cache-cleanup execution.

[eygraber]

Is there an ETA on when the fix will be released?

[bigdaz]

Is there an ETA on when the fix will be released?

Within 24hrs.

[mikehardy]

This doesn't seem to be working for me for some reason, and I can't figure it out

https://github.com/ankidroid/Anki-Android-Backend/actions/runs/11806510718/job/32891289096#step:42:50

We still seem to be seeing the error where the old internal gradle API symbol is in use but I'm certain the run was after your fix+release, and we're using the v4 tag, which I just verified was moved in this repository to reference the new code.

Very strange - I'm going to have to employ the workaround's in the linked issues for now

edit: was using v3, not the version I thought I was using, the version with the fix - v4

[mikehardy]

Never mind - it appears I was still on v3 tag for whatever reason.
So I also need to change my dependabot config to propose pulls for actions
Apologies for the noise, thanks for the fix

[JojOatXGME]

Note that this issue still exists for setup-gradle@v3 with gradle-home-cache-cleanup: true. It looks like the action just downloads the latest version of Gradle, ignoring the Gradle version configured on the action. The action started to fail without any changes on the repository after Gradle 8.11 was released.

FAILURE: Build failed with an exception.

* Where:
Initialization script '/home/runner/work/_temp/dummy-cleanup-project/init.gradle' line: 8

* What went wrong:
Cannot get the value of write-only property 'removeUnusedEntriesOlderThan' for object of type org.gradle.api.internal.cache.DefaultCacheConfigurations$DefaultCacheResourceConfiguration.

Do you plan to fix the issue for v3? In the future, it would probably be better to use a specific Gradle version to reduce the number of variables which can lead to unrepeatable builds in the future.

[bigdaz]

Do you plan to fix the issue for v3? In the future, it would probably be better to use a specific Gradle version to reduce the number of variables which can lead to unrepeatable builds in the future.

Thanks for your feedback. Unfortunately there's no easy solution to this problem. A specific Gradle version will not cleanup files from newer versions, so if setup-gradle cleanup was tied to a fixed Gradle version, it would fail to ever cleanup Gradle User Home for later Gradle versions.

So in your case of using Gradle 8.11 with setup-gradle@v3, the build wouldn't fail but the gradle-home-cache-cleanup parameter would have no effect.

I'll raise a separate issue for this breakage with setup-gradle@v3. Is there a reason that you are unable to upgrade to v4?

[bigdaz]

Raise #469 for the issue with setup-gradle@v3.

[JojOatXGME]

Is there a reason that you are unable to upgrade to v4?

No. I actually already switched to v4 after writing my last message. Since gradle-home-cache-cleanup was experimental in v3 anyway (I think), I wouldn't consider fixing v3 too much of a priority.

I was mostly writing my comment because, first, I wanted to make you aware that the issue also exists on v3. And second, I wanted to highlight that the design wasn't ideal, and similar scenarios should be avoided in the future. In my opinion, just downloading the latest version of Gradle is a bit like asking for trouble. A better approach might have been to choose the configured version (i.e. the version specified by the wrapper by default), and fallback to 8.9 if the wrapper specifies an earlier version not supported by the feature.

[bigdaz]

@JojOatXGME Thanks. Yes we are well aware that the current solution isn't ideal, and the plan is to do exactly as you suggest:

• Collect all Gradle versions executed during the workflow. This could be the configured wrapper, but could also be defined separately.
• Run cache cleanup with the newest of: [versions executed] + Gradle 8.11 (or some fixed version)

This way, cache cleanup could still start to fail if a build bumps to a newer Gradle version that has an incompatible cleanup API. But it won't start to fail just because a newer Gradle version is released.

This issue is already tracked as #436