Changing the version of a hermit-managed protoc binary causes the gradle plugin to incorrectly re-use previous output

[staktrace]

We recently had a situation where we are configuring a project like so:

protobuf {
  protoc {
    path = "$rootDir/bin/protoc"
  }
  ...

And the binary at $rootDir/bin/protoc was updated from one version to another (v3.21 to v22). However, this change did not result in the gradle plugin re-running the generateProto task; instead it reused the cached results, resulting in (for us) subsequent breakage later.

The protoc binary in use should be annotated as an input to the task so that gradle knows to re-run the task if it changes.

[staktrace]

(This was using com.google.protobuf:protobuf-gradle-plugin:0.8.18)

[staktrace]

Ah, looks like this is a duplicate of #557 and was fixed in 0.8.19. I will verify locally and then close this issue if I'm able to confirm.

[staktrace]

So with 0.8.19, it looks like this works in the usual case where the protoc binary is pointed to by the path property, or if the protoc binary is pointed to by a chain of symlinks pointed to by the path property.

Unfortunately, in our case, we are using a tool called hermit (https://cashapp.github.io/hermit/) to manage our binary tools. So in this case the chain of symlinks terminates at the hermit wrapper script, which is the same when we're using protoc-22.0 or protoc-3.21.5. The way it works is bin/protoc is a symlink to bin/.protoc-3.21.5.pkg which is a symlink to bin/hermit which is a shell script that exec's protoc-3.21.5, and similarly for protoc-22.0.

I don't think this is something that can/should really be addressed in this gradle plugin, so I'm going to close this issue and bring it up with the hermit folks instead.

[staktrace]

Actually I guess one thing that might help here is if the plugin took the output of protoc --version and used that as part of the cache fingerprint as well.

[staktrace]

Since this is issue is a combination of hermit and this plugin, it doesn't seem like either of these are the right place for the fix. I ended up putting a fix in another component we use that was one level up on the abstraction ladder.