This message was deleted.

Well, what would you suggest to do about it? 🙂

For my setup I aligned these 2 jars — replaced the one installed in CI image with the one that was common for devs so that now build cache input keys are also aligned. I also created an issue in Google IssueTracker, but I lack permission to create it in appropriate component, so I’m not sure that it’ll be processed appropriately 🙁

The question maybe is, what is different and does that have a reason. Iirc not the checksum of the JAR is relevant for the cache key, but only the ABI, because if you compile against the same ABI, the same result comes out. So could it be that those two jars have a different ABI?

I agree that ABI acts as cache key input, but since it’s easier and faster to operate with checksum in order to demonstrate deviation — I went with this option. Imho it doesn’t seem right that ABI of this jar changed (if changed) only for single platform and not for all simultaneously.

you didn't say which tasks were impacted, so it's possible that it's a runtime classpath input, in which case it's the full jar that matters, not just the abi don't worry about creating on the wrong component. that's by design. Google found that devs almost never picked the right component, so they limited what you could select and they move it as appropriate when they triage. but I would suggest you update the issue with the specific tasks that are impacted

Thanks for the note, I’ve updated the issue.

compile*Kotlin

tasks were impacted in the first place so, as I understand, these jars differ in ABI

Sorry, I missed the issue you linked above and just filed a new one with more information (as I looked inside the jars). New issue is here.