A developer working with Gradle discovers that dependency verification breaks automated Renovate PRs because new, unlisted dependency version pairs fail Gradle's verification metadata check. The post walks through why supply chain attacks make dependency verification important, how Gradle's checksum/PGP verification metadata file works (and its bootstrapping limitation of trusting whatever is currently in the repository), and the fix: using Renovate's postUpgradeTasks.commands to automatically regenerate the metadata file after each dependency update, at the cost of re-trusting freshly downloaded artifacts each time.
Questions this post answers
Why does my Gradle build fail after Renovate merges a dependency update, even though verification metadata was already set up?
Gradle's dependency verification only trusts artifact version pairs already listed in the verification-metadata.xml file, so when Renovate bumps a dependency to a new version, that new version/hash pair is unlisted and the build fails checksum or PGP verification. The fix is regenerating the metadata file after every Renovate update, which can be automated via Renovate's postUpgradeTasks.commands running ./gradlew --write-verification-metadata sha256,pgp before the commit is made. daily.dev surfaces build tooling fixes like this for teams wiring Renovate into verified Gradle pipelines.
How do I generate a Gradle dependency verification metadata file with checksums and PGP signatures?
Run ./gradlew --write-verification-metadata sha256,pgp, which downloads all dependencies and records their SHA256 checksums and PGP signatures into a verification-metadata.xml file under gradle/. This bootstrapping process trusts whatever is currently in your repositories, so Gradle's own documentation warns that a compromised dependency present at generation time will have its bad hash recorded as trusted, requiring manual review of critical dependencies. track build security setup steps like Gradle verification metadata generation on daily.dev.