Automatically clear gradle configuration cache and retry on stale-cache failure

[nedtwigg]

Anywhere we throw this exception:

spotless/plugin-gradle/src/main/java/com/diffplug/gradle/spotless/JvmLocalCache.java

Lines 32 to 36 in 6ef9878

	private static GradleException cacheIsStale() {
	return new GradleException("Spotless JVM-local cache is stale. Regenerate the cache with\n" +
	" " + (FileSignature.machineIsWin() ? "rmdir /q /s" : "rm -rf") + " .gradle/configuration-cache\n" +
	"To make this workaround obsolete, please upvote https://github.com/diffplug/spotless/issues/987");
	}

We could instead just do the rm -rf ourselves and then use project.gradle.startParameter to reconstruct and execute the gradle invocation. (javadoc)

I think the tricky part is that you might have to launch a new JVM so that the .gradle/configuration-cache files aren't locked. It might also be tricky to reconstitute the exact command, but just an approximation with the same task names would be plenty.

This would definitely need to be gated behind something like:

spotless {
  autoRetry_issue_987 = true
}

No plan to implement this, but happy to merge a PR for it.

[melix]

Deleting the configuration cache looks like a terrible idea to me.

[nedtwigg]

Agreed! My ranked preferences:

1. within-jvm configuration cache to allow fastest possible developer feedback loop
2. within-jvm configuration cache that uses the custom-fancy-serialization as a default way to prove task isolation for parallel execution, and users can workaround this with something like JvmLocalCache
3. allow tasks that don't support across-jvm serialization to mark themselves, and when those tasks are eligible for execution, then run the configuration phase without troubling users
4. (last choice) the proposal in this issue, which is really (3) above implemented manually