Allow action to save/restore configuration-cache state on runners with persistent Gradle User Home

[milis92]

Action will ignore saving/restoring configuration cache from the projects .gradle directory if it detects that Gradle User home exists on the host.

Logs from the gradle-build-action setup step:

Run gradle/gradle-build-action@v2
  with:
    cache-read-only: false
    gradle-version: wrapper
    cache-disabled: false
    cache-write-only: false
    gradle-home-cache-includes: caches
  notifications
  
    generate-job-summary: true
    gradle-home-cache-strict-match: false
    workflow-job-context: null
Gradle User Home already exists: will not restore from cache.

Following task execution:

Run ./gradlew ktLintCheck
Starting a Gradle Daemon, 1 busy and 1 stopped Daemons could not be reused, use --status for details
Configuration cache is an incubating feature.
Configuration on demand is an incubating feature.
Calculating task graph as no configuration cache is available for tasks: ktLintCheck

The desired outcome would be to restore configuration cache independently of restoring GRADLE_HOME state

[bigdaz]

Thanks for you report. Indeed it could make sense to be able to save/restore the configuration-cache state even with a persistent Gradle User Home. There are a couple of things we'd need to change to make this work:

• The current mechanism saves an effective index of cache entries to restore inside files like ~/.gradle/.cache-base/*-entry-metadata.json. I think this could be changed to live outside of the Gradle User Home (at least for the configuration cache)
• The configuration cache is tightly dependent on the contents of Gradle User Home, and Gradle (with config cache) will fail in strange ways when the Gradle User Home doesn't have the expected files present. So we only restore config-cache if Gradle User Home is fully restored](https://github.com/gradle/gradle-build-action/blob/main/src/cache-extract-entries.ts#L361-L370). I'm not yet sure how to resolve this.

[milis92]

I did a bit of research on the second topic and based on Sharing configuration cache section, this doesn't seem like a good idea after all.

Persisted Gradle Home is only possible on self-hosted runners that could have an infinite number of different environments. In setups like these, it's recommended not to use configuration caching because there are just so many things(checkout paths, env variables, os, etc) that would break configuration caching.

I'm proposing 2 options:

1. I would say this is blocked by https://github.com/gradle/gradle/issues/13510 and work related to this issue should be postponed until 13510 is resolved and the configuration cache is decoupled from the environment.
2. We could go with an experimental opt-in config flag that would restore the configuration cache without any kind of checks on the Gradle Home.

[bigdaz]

Since the configuration-cache can contain sensitive information, the gradle-build-action no longer attempts to save and restore this information in the GitHub Actions cache: https://github.com/gradle/gradle-build-action/security/advisories/GHSA-h3qr-39j9-4r5v.

As such, this issue is no longer relevant, since the behaviour is the same for self-hosted and github-hosted runners.