Gradle依赖验证搭配Renovate自动化升级的实操避坑指南

公司推进构建标准化选型Gradle配合Kotlin DSL时，原本想靠Gradle从6.1版本开始内置的依赖验证机制守住供应链安全，没想到和Renovate自动化升级工具配合时踩了不少坑。
这套机制运行逻辑很直白：靠verification-metadata.xml文件留存每个artifact的SHA-256或SHA-512哈希值，构建阶段Gradle会自动比对下载的依赖包和记录值是否一致，原理上足够可靠，但和Renovate凑到一起就成了自动化流程里的卡点。
最常出现的问题是：Renovate监测到依赖新版本自动提交升级PR时，gradle.lockfile已经更新，但verification-metadata.xml里记录的还是旧版本的哈希值，直接导致CI构建阶段报哈希不匹配错误。
官方文档给出的解决思路很简单，只要执行gradle --write-verification-metadata sha256就能自动补全缺失的哈希值，但实际操作里我碰过两个容易忽略的坑，大家可以提前规避：
其一是多模块项目的执行路径限制。如果只在单个子模块目录下执行该命令，Gradle大概率没法完整捕获所有传递依赖（Transitive Dependencies）的哈希，生成的metadata文件会出现缺漏，这个命令必须在根工程（Root Project）目录下执行，才能覆盖全量全局依赖。
其二是Renovate PR的闭环问题。Renovate本身只会修改依赖版本号，既没有权限也没法在CI环境里执行Gradle命令再把生成的XML文件回传到PR里，如果开启依赖验证，每一条升级PR都会因为哈希值缺失直接失败，最后还是要人工跑命令、提交代码，完全不符合自动化的预期。
为了解决这个矛盾，我搭了一套自动补全的CI链路。核心思路是把metadata文件纳入版本控制，同时在GitHub Actions流程里加一个拦截环节：只要检测到dependencies.lock发生变更，且verification-metadata.xml里缺少对应条目，就由CI自动执行生成命令，把更新后的XML文件追加提交到当前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，这样CI才有权限在补全校验信息后把生成的metadata推回仓库。这么操作后，依赖升级PR刚提交时会先失败一次，触发CI自动补全后再跑一次构建就能变绿，真正实现无人值守的依赖升级。
最后说下安全性的考量。很多人疑惑为什么不直接用JAR签名，其实这套方案在当前生态里基本已经失效了：Maven Central基本只提供哈希校验，不提供可靠的签名验证能力，Gradle选择做「完整性校验（Integrity）」而非「真实性校验（Authenticity）」本身也是务实的妥协。
如果对供应链安全的要求极高，单靠SHA-256已经不够用了，可以进一步研究SLSA provenance和Sigstore这套工具链。但对多数企业级项目来说，把Gradle依赖验证和自动化升级闭环跑通，已经能过滤掉90%左右的依赖篡改风险了。