Context

This PR is a proof of concept, just for possible discussion, curious about opinions of Gradle maintainers as well. In the prototype the BuildCacheKey is exposed in the org.gradle.api.internal.cache package assuming there is no guarantee of forward compatibility unless it's clarified.

Some tasks may need Gradle calculated cache key to align standard cache semantics, not to duplicate artifact hash itself.
E.g. there are web artifact compiling tasks, that produce output with URL query parameters like ...?v={version} where version can be random UUID or git commit or timestamp or whatever. The similar approach can be helpful if the output creates some manifest with unique build id.

The idea of this change is to reuse the Gradle build cache in the task.

Advantages:

• reproducible between sequential builds between local and CI/CD environment (if there is a remote cache)
• different if there are different task Inputs
• aligned with Gradle cache mechanism

But it has a major drawback: if the build is executed without build cache, Gradle skips cache calculation. So the task output will not be reproducible between --build-cache and --no-build-cache

Alternative solutions

Manually calculate build cache key in the task implementation - taking into calculation at least:

• all inputs respecting absolute/relative file name sensitivity
• buildSrc/task implementation hash
• any implicit parameters like build properties

Contributor Checklist

• Review Contribution Guidelines.
• Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team.
• Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective.
• Provide unit tests (under <subproject>/src/test) to verify logic.
• Update User Guide, DSL Reference, and Javadoc for public-facing changes.
• Ensure that tests pass sanity check: ./gradlew sanityCheck.
• Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest.

Reviewing cheatsheet

Before merging the PR, comments starting with

• ❌ ❓must be fixed
• 🤔 💅 should be fixed
• 💭 may be fixed
• 🎉 celebrate happy things