公司标准化选了 Gradle，Kotlin DSL 写得挺规范

Gradle 从 6.1 开始内置依赖验证，核心思路是把 verification-metadata.xml 里记好每个 artifact 的 SHA-256/512。Renovate 提 PR 升版本时，lockfile 变了，但 metadata 里还是旧哈希，构建自然过不去。文档里说得轻巧，跑 gradle --write-verification-metadata sha256 就能自动补全，实际操作起来有两个坑：一是多模块项目得在根工程跑，子模块单独跑会漏传递依赖；二是 Renovate 的 PR 里没法直接跑这命令，得在 CI 里预先生成好 metadata 再提交，或者配 Renovate 的 automerge 配合 postUpdateOptions。

我选的路子是把 metadata 纳入版本控制，CI 里加个步骤：检测到 dependencies.lock 变动且 metadata 里缺对应条目，就自动跑生成命令并追加提交到同一个 PR。Renovate 端配成这样：

{
  "packageRules": [
    {
      "matchManagers": ["gradle"],
      "postUpdateOptions": ["gomodTidy"]
    }
  ],
  "gradle": {
    "fileMatch": ["**/build.gradle.kts", "**/settings.gradle.kts"]
  }
}

配合 GitHub Actions 里的 gradle/gradle-build-action，在 cache-read-only: false 下让它有写权限把生成的 metadata 推回去。现在依赖升级 PR 能自动补全校验信息，合并前跑一遍完整构建就绿了。

顺便说句实在的：JAR 签名那套早死透了，Maven Central 只给哈希不给签名，Gradle 选完整性校验而非真实性校验也是无奈之举。供应链安全真要上强度，还得看 SLSA provenance 和 Sigstore 那套，但这又是另一套工具链的事了。