Daz DeBoer

> Do we have an update on this? Not really. The current PR is a bit problematic (assumes Gradle project is root of repository), and I'm not sure when we'll...

@DPUkyle asked me to take a look at this failure based on my GitHub actions experience. - The [correct git SHA being cloned by the action](https://github.com/ben-manes/gradle-versions-plugin/actions/runs/3061921296/jobs/4942286933#step:2:416), which is the [merge...

Looks like an updated Gradle version didn't help. Next thing to try would be running the workflow with `cache-disabled: true`. That will cause the CI build to run with a...

Should be fixed by #161

This should be fixed by #167

Self hosted runners require 'unzip'.

> @bigdaz is there also a way to influence the age of cache entries to be retained? @sschuberth Can you explain why you'd want to do that? The present functionality...

> But if you're saying that the current implementation of gradle-home-cache-cleanup: true already does not keep (or save / restore) any cache entries from previous days / builds, I believe...

@cloudshiftchris This sounds like a different issue, and something we should investigate and fix. Can you please open a separate GH issue with as much detail as possible? Thanks.

@tbroyer `v2.8.0` will provide a `gradle-version` output parameter, closing this issue. However, I've opened gradle/actions#22 for the key use case of avoiding re-download of Gradle distributions.