google / google/protobuf-gradle-plugin
Cache miss in `GenerateProtoTask` caused by input `javaExecutablePath`
- Dominant language
- Groovy
- Stars
- 1.8k
- Forks
- 288
- PR merge metrics
- No merged PRs in 30d
Description
We have observed cache misses for the `GenerateProtoTask` tasks in projects using the plugin since version 0.9.5.
The issue occurs when different Java executable paths are used. This is reproducible in scenarios where we attempt to reuse the cached output of the task, but the build runs in an environment with a different Java path than the one that populated the remote cache.
For example, in two builds for the same commit—one running in CI and another locally—we see a cache key difference because the input javaExecutablePath differs:
(build A is CI and B is local)
If we add this input as a custom value in the build scan, we can confirm the difference that impacts the cache outcome:
The expectation is that this path should not influence the cache key, or there should be a way to normalize it to avoid unnecessary cache misses.
Contributor guide
Research direction
Start by locating GenerateProtoTask and tracing how its javaExecutablePath input contributes to the Gradle cache key. Reproduce the CI-versus-local cache miss described in the issue, then verify that equivalent builds with different Java executable paths no longer produce an unnecessary cache miss.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- groovy, java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100