Renovate Cloud Build Manager 详解自动提取并更新 Google Cloud Build 配置中的 Docker 镜像依赖【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 的cloudbuildmanager 专门负责从 Google Cloud Build 为核心结合该模块的源码实现、测试用例与示例配置完整讲解其工作原理、可识别的镜像形态、版本化处理方式以及如何在你的仓库中启用它。Cloud Build manager 是什么在 Renovate 的 manager 体系中cloudbuild是一个专门面向 Google Cloud BuildGoogle 提供的托管式 CI/CD 服务配置文件的依赖提取器。它的核心职责只有一件事读取 Cloud Build 配置文件中的steps列表把每个 step 的name字段当作一个 Docker 镜像依赖提取出来交给dockerdatasource 做版本比较与更新。从 lib/modules/manager/cloudbuild/index.ts 的模块元信息可以清晰看到它的定位export const displayName Cloud Build; export const url https://cloud.google.com/build/docs; export const categories: Category[] [ci]; export const supportedDatasources [DockerDatasource.id];categories属于ci持续集成类 manager与 GitHub Actions、GitLab CI 等同类supportedDatasources只支持docker一种 datasource即所有被提取的依赖都按容器镜像处理。匹配哪些文件默认文件匹配规则cloudbuildmanager 默认只处理 Cloud Build 的配置文件。在 lib/modules/manager/cloudbuild/index.ts 中通过defaultConfig声明了默认匹配模式export const defaultConfig { managerFilePatterns: [/(^|/)cloudbuild\\.ya?ml/], };这条正则的含义是文件名必须为cloudbuild.yaml或cloudbuild.yml且可以出现在仓库任意层级目录下(^|/)匹配路径开头或目录分隔符。也就是说cloudbuild.yaml、cloudbuild.yml仓库根目录✅.cloudbuild/cloudbuild.yaml、config/cloudbuild.yml任意子目录✅my-cloudbuild.yaml文件名前缀不符❌cloudbuild.jsonCloud Build 也支持 JSON 格式配置但 manager 默认不处理❌如果你的 Cloud Build 配置文件使用了非默认的命名例如通过--config参数指定的build-config.yaml你可以在 Renovate 配置中通过fileMatch覆盖或补充匹配规则例如{ cloudbuild: { fileMatch: [(^|/)cloudbuild\\.ya?ml$, (^|/)build-config\\.ya?ml$] } }提取流程从 YAML 到依赖列表整个提取过程非常精简是一条清晰的解析 → 转换 → 归一化流水线。我们按源码逐层拆解。第一步Zod 模式解析 YAMLlib/modules/manager/cloudbuild/schema.ts 定义了数据校验模式它复用了 Renovate 的工具链zod v4 与Yaml解析器import { z } from zod/v4; import { LooseArray, Yaml } from ../../../util/schema-utils/index.ts; export const CloudbuildSteps Yaml.pipe( z .object({ steps: LooseArray( z.object({ name: z.string() }).transform(({ name }) name), ), }) .transform(({ steps }) steps), );几个值得注意的设计细节Yaml.pipe(...)先把整个文件内容按 YAML 解析成对象再交给 zod 校验避免手工处理缩进与引号问题steps是必需的Cloud Build 配置文件的核心是steps数组options、timeout、tags、images等顶层字段与本 manager 无关不会被处理LooseArray宽松数组允许数组中混入未知元素而不整体报错提升了容错性每个 step 只取nametransform(({ name }) name)把 step 对象规约为镜像名字符串这是该 step 使用的容器镜像。第二步逐 step 提取依赖lib/modules/manager/cloudbuild/extract.ts 是提取入口export function extractPackageFile( content: string, packageFile?: string, ): PackageFileContent | null { const deps CloudbuildSteps.catch(({ error: err }) { logger.debug( { err, packageFile }, Cloud Build: error extracting Docker images from a configuration file., ); return []; }) .transform((steps) steps.map((step) getDep(step))) .parse(content); if (!deps.length) { return null; } return { deps }; }解析失败时如文件不是合法 YAML、缺少steps不会抛错中断任务而是记录 debug 日志并返回空数组这是 Renovate 一贯的容错策略解析成功后每个 step 的镜像名都会交给getDep()做归一化见下文若最终没有任何依赖返回null表示此文件无需 Renovate 处理。第三步getDep()归一化镜像依赖getDep()定义在 lib/modules/manager/dockerfile/extract.ts是 Dockerfile manager 与 cloudbuild manager 共用的镜像解析函数。它会校验镜像名非空否则标记skipReason: invalid-value按拆分 digest如namesha256:...按最后一个:拆分 tag生成标准化的PackageDependency结构depName镜像仓库路径、currentValue当前 tag、currentDigest当前 digest支持 registry alias 解析处理$CI_REGISTRY这类变量前缀的镜像附带版本化推断当镜像为ubuntu或以/ubuntu结尾时自动使用ubuntu版本化当镜像为debian且 tag 是合法 Debian 版本时自动使用debian版本化见 extract.ts。最终产出形如下面的依赖对象{ depName: gcr.io/cloud-builders/docker, packageName: gcr.io/cloud-builders/docker, currentValue: 19.03.8, datasource: docker }实际示例能从配置里提取到什么仓库自带的示例文件 lib/modules/manager/cloudbuild/fixtures/cloudbuild.yml 展示了一个典型的 Cloud Build 配置steps: - name: gcr.io/cloud-builders/docker:19.03.8 args: [build, -t, gcr.io/my-project/my-image, .] timeout: 500s - name: node:12 entrypoint: npm args: [test] - name: gcr.io/cloud-builders/kubectl args: [set, image, deployment/my-deployment, my-containergcr.io/my-project/my-image] env: - CLOUDSDK_COMPUTE_ZONEus-east4-b - CLOUDSDK_CONTAINER_CLUSTERmy-cluster options: machineType: N1_HIGHCPU_8 timeout: 660s tags: [mytag1, mytag2] images: [gcr.io/my-project/myimage]对照 lib/modules/manager/cloudbuild/extract.spec.ts 中的断言这段配置会被提取为 3 个依赖stepnamedepNamecurrentValue说明gcr.io/cloud-builders/docker:19.03.8gcr.io/cloud-builders/docker19.03.8带 tag 的镜像node:12node12Docker Hub 官方镜像gcr.io/cloud-builders/kubectlgcr.io/cloud-builders/kubectl无未固定 tag只跟踪 digest/最新几个值得注意的点只关注steps[].nameargs、entrypoint、env、options、tags、images等字段都不会触发依赖提取。即使images列表里写了gcr.io/my-project/myimage它也不是构建产物镜像不会被更新未固定 tag 的镜像kubectl这种没有 tag 的依赖Renovate 无法比较版本通常只能跟踪 digest 更新或在镜像发布新 tag 时给出提示step 数量 依赖数量每个 step 的name都是一个独立依赖全部纳入一个 PR 分支统一处理取决于你的packageRules与separateMultipleMajor等配置。版本化versioning如何处理原文档特别提醒如果你需要修改版本格式请阅读 versioning 文档。这是因为cloudbuildmanager 本身不做任何版本比较——它只负责提取依赖判断哪个版本更新是 versioning 模块的职责。cloudbuild 依赖项默认使用docker版本化规则其核心特点包括将镜像 tag 后缀如-alpine、-slim视为兼容性后缀而非主版本号的一部分适合大多数多标签镜像仓库Docker Hub、GCR、Artifactory 等。当你发现某个镜像的更新行为不符合预期时典型的处理方式是在 Renovate 配置中为特定依赖覆盖版本化规则。例如若gcr.io/my-org/app严格遵循 SemVer可以这样配置{ packageRules: [ { matchDatasources: [docker], matchPackageNames: [gcr.io/my-org/app], versioning: semver } ] }从源码上看getDep()内部还会对ubuntu、debian镜像自动切换对应的版本化模块见 dockerfile/extract.ts因此这两类系统镜像会按各自的发布节奏如 Debian 代号/版本号被正确比较。如何启用与验证cloudbuildmanager 属于 Renovate 的默认启用 manager你通常无需显式开启。只要仓库中存在符合/(^|/)cloudbuild\.ya?ml/规则的文件Renovate 扫描时就会自动执行提取。若想确认提取结果是否正确可以本地跑 Renovate 的 dry-runnpx renovate --dry-run具体参数见 docs/usage/getting-started/running.md查看日志提取阶段解析失败会在日志中出现Cloud Build: error extracting Docker images from a configuration file.对应 extract.ts 中的 debug 日志可用它定位配置格式问题检查生成的依赖面板Renovate 会把提取到的depName、currentValue、datasource展示在依赖 Dashboard 中直接核对镜像名与 tag 是否符合预期。小结cloudbuildmanager 是 Renovate 面向 Google Cloud Build 场景的轻量级接入点它用不到 30 行核心代码完成了解析 Cloud Build 配置 → 提取 steps 镜像 → 归一化为 docker 依赖的完整闭环并把版本比较、PR 生成等重活交给下游的dockerdatasource 与 versioning 模块。对于所有把 CI 跑在 Cloud Build 上、且构建步骤依赖固定版本镜像的仓库启用它即可让镜像版本随上游发布自动保持最新。如果你希望深入了解其提取行为的细节建议继续阅读提取实现lib/modules/manager/cloudbuild/extract.ts模式定义lib/modules/manager/cloudbuild/schema.ts测试用例lib/modules/manager/cloudbuild/extract.spec.ts复用的镜像解析函数lib/modules/manager/dockerfile/extract.ts版本化机制总览lib/modules/versioning/index.md【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Renovate Cloud Build Manager 详解自动提取并更新 Google Cloud Build 配置中的 Docker 镜像依赖【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 的cloudbuildmanager 专门负责从 Google Cloud Build 为核心结合该模块的源码实现、测试用例与示例配置完整讲解其工作原理、可识别的镜像形态、版本化处理方式以及如何在你的仓库中启用它。Cloud Build manager 是什么在 Renovate 的 manager 体系中cloudbuild是一个专门面向 Google Cloud BuildGoogle 提供的托管式 CI/CD 服务配置文件的依赖提取器。它的核心职责只有一件事读取 Cloud Build 配置文件中的steps列表把每个 step 的name字段当作一个 Docker 镜像依赖提取出来交给dockerdatasource 做版本比较与更新。从 lib/modules/manager/cloudbuild/index.ts 的模块元信息可以清晰看到它的定位export const displayName Cloud Build; export const url https://cloud.google.com/build/docs; export const categories: Category[] [ci]; export const supportedDatasources [DockerDatasource.id];categories属于ci持续集成类 manager与 GitHub Actions、GitLab CI 等同类supportedDatasources只支持docker一种 datasource即所有被提取的依赖都按容器镜像处理。匹配哪些文件默认文件匹配规则cloudbuildmanager 默认只处理 Cloud Build 的配置文件。在 lib/modules/manager/cloudbuild/index.ts 中通过defaultConfig声明了默认匹配模式export const defaultConfig { managerFilePatterns: [/(^|/)cloudbuild\\.ya?ml/], };这条正则的含义是文件名必须为cloudbuild.yaml或cloudbuild.yml且可以出现在仓库任意层级目录下(^|/)匹配路径开头或目录分隔符。也就是说cloudbuild.yaml、cloudbuild.yml仓库根目录✅.cloudbuild/cloudbuild.yaml、config/cloudbuild.yml任意子目录✅my-cloudbuild.yaml文件名前缀不符❌cloudbuild.jsonCloud Build 也支持 JSON 格式配置但 manager 默认不处理❌如果你的 Cloud Build 配置文件使用了非默认的命名例如通过--config参数指定的build-config.yaml你可以在 Renovate 配置中通过fileMatch覆盖或补充匹配规则例如{ cloudbuild: { fileMatch: [(^|/)cloudbuild\\.ya?ml$, (^|/)build-config\\.ya?ml$] } }提取流程从 YAML 到依赖列表整个提取过程非常精简是一条清晰的解析 → 转换 → 归一化流水线。我们按源码逐层拆解。第一步Zod 模式解析 YAMLlib/modules/manager/cloudbuild/schema.ts 定义了数据校验模式它复用了 Renovate 的工具链zod v4 与Yaml解析器import { z } from zod/v4; import { LooseArray, Yaml } from ../../../util/schema-utils/index.ts; export const CloudbuildSteps Yaml.pipe( z .object({ steps: LooseArray( z.object({ name: z.string() }).transform(({ name }) name), ), }) .transform(({ steps }) steps), );几个值得注意的设计细节Yaml.pipe(...)先把整个文件内容按 YAML 解析成对象再交给 zod 校验避免手工处理缩进与引号问题steps是必需的Cloud Build 配置文件的核心是steps数组options、timeout、tags、images等顶层字段与本 manager 无关不会被处理LooseArray宽松数组允许数组中混入未知元素而不整体报错提升了容错性每个 step 只取nametransform(({ name }) name)把 step 对象规约为镜像名字符串这是该 step 使用的容器镜像。第二步逐 step 提取依赖lib/modules/manager/cloudbuild/extract.ts 是提取入口export function extractPackageFile( content: string, packageFile?: string, ): PackageFileContent | null { const deps CloudbuildSteps.catch(({ error: err }) { logger.debug( { err, packageFile }, Cloud Build: error extracting Docker images from a configuration file., ); return []; }) .transform((steps) steps.map((step) getDep(step))) .parse(content); if (!deps.length) { return null; } return { deps }; }解析失败时如文件不是合法 YAML、缺少steps不会抛错中断任务而是记录 debug 日志并返回空数组这是 Renovate 一贯的容错策略解析成功后每个 step 的镜像名都会交给getDep()做归一化见下文若最终没有任何依赖返回null表示此文件无需 Renovate 处理。第三步getDep()归一化镜像依赖getDep()定义在 lib/modules/manager/dockerfile/extract.ts是 Dockerfile manager 与 cloudbuild manager 共用的镜像解析函数。它会校验镜像名非空否则标记skipReason: invalid-value按拆分 digest如namesha256:...按最后一个:拆分 tag生成标准化的PackageDependency结构depName镜像仓库路径、currentValue当前 tag、currentDigest当前 digest支持 registry alias 解析处理$CI_REGISTRY这类变量前缀的镜像附带版本化推断当镜像为ubuntu或以/ubuntu结尾时自动使用ubuntu版本化当镜像为debian且 tag 是合法 Debian 版本时自动使用debian版本化见 extract.ts。最终产出形如下面的依赖对象{ depName: gcr.io/cloud-builders/docker, packageName: gcr.io/cloud-builders/docker, currentValue: 19.03.8, datasource: docker }实际示例能从配置里提取到什么仓库自带的示例文件 lib/modules/manager/cloudbuild/fixtures/cloudbuild.yml 展示了一个典型的 Cloud Build 配置steps: - name: gcr.io/cloud-builders/docker:19.03.8 args: [build, -t, gcr.io/my-project/my-image, .] timeout: 500s - name: node:12 entrypoint: npm args: [test] - name: gcr.io/cloud-builders/kubectl args: [set, image, deployment/my-deployment, my-containergcr.io/my-project/my-image] env: - CLOUDSDK_COMPUTE_ZONEus-east4-b - CLOUDSDK_CONTAINER_CLUSTERmy-cluster options: machineType: N1_HIGHCPU_8 timeout: 660s tags: [mytag1, mytag2] images: [gcr.io/my-project/myimage]对照 lib/modules/manager/cloudbuild/extract.spec.ts 中的断言这段配置会被提取为 3 个依赖stepnamedepNamecurrentValue说明gcr.io/cloud-builders/docker:19.03.8gcr.io/cloud-builders/docker19.03.8带 tag 的镜像node:12node12Docker Hub 官方镜像gcr.io/cloud-builders/kubectlgcr.io/cloud-builders/kubectl无未固定 tag只跟踪 digest/最新几个值得注意的点只关注steps[].nameargs、entrypoint、env、options、tags、images等字段都不会触发依赖提取。即使images列表里写了gcr.io/my-project/myimage它也不是构建产物镜像不会被更新未固定 tag 的镜像kubectl这种没有 tag 的依赖Renovate 无法比较版本通常只能跟踪 digest 更新或在镜像发布新 tag 时给出提示step 数量 依赖数量每个 step 的name都是一个独立依赖全部纳入一个 PR 分支统一处理取决于你的packageRules与separateMultipleMajor等配置。版本化versioning如何处理原文档特别提醒如果你需要修改版本格式请阅读 versioning 文档。这是因为cloudbuildmanager 本身不做任何版本比较——它只负责提取依赖判断哪个版本更新是 versioning 模块的职责。cloudbuild 依赖项默认使用docker版本化规则其核心特点包括将镜像 tag 后缀如-alpine、-slim视为兼容性后缀而非主版本号的一部分适合大多数多标签镜像仓库Docker Hub、GCR、Artifactory 等。当你发现某个镜像的更新行为不符合预期时典型的处理方式是在 Renovate 配置中为特定依赖覆盖版本化规则。例如若gcr.io/my-org/app严格遵循 SemVer可以这样配置{ packageRules: [ { matchDatasources: [docker], matchPackageNames: [gcr.io/my-org/app], versioning: semver } ] }从源码上看getDep()内部还会对ubuntu、debian镜像自动切换对应的版本化模块见 dockerfile/extract.ts因此这两类系统镜像会按各自的发布节奏如 Debian 代号/版本号被正确比较。如何启用与验证cloudbuildmanager 属于 Renovate 的默认启用 manager你通常无需显式开启。只要仓库中存在符合/(^|/)cloudbuild\.ya?ml/规则的文件Renovate 扫描时就会自动执行提取。若想确认提取结果是否正确可以本地跑 Renovate 的 dry-runnpx renovate --dry-run具体参数见 docs/usage/getting-started/running.md查看日志提取阶段解析失败会在日志中出现Cloud Build: error extracting Docker images from a configuration file.对应 extract.ts 中的 debug 日志可用它定位配置格式问题检查生成的依赖面板Renovate 会把提取到的depName、currentValue、datasource展示在依赖 Dashboard 中直接核对镜像名与 tag 是否符合预期。小结cloudbuildmanager 是 Renovate 面向 Google Cloud Build 场景的轻量级接入点它用不到 30 行核心代码完成了解析 Cloud Build 配置 → 提取 steps 镜像 → 归一化为 docker 依赖的完整闭环并把版本比较、PR 生成等重活交给下游的dockerdatasource 与 versioning 模块。对于所有把 CI 跑在 Cloud Build 上、且构建步骤依赖固定版本镜像的仓库启用它即可让镜像版本随上游发布自动保持最新。如果你希望深入了解其提取行为的细节建议继续阅读提取实现lib/modules/manager/cloudbuild/extract.ts模式定义lib/modules/manager/cloudbuild/schema.ts测试用例lib/modules/manager/cloudbuild/extract.spec.ts复用的镜像解析函数lib/modules/manager/dockerfile/extract.ts版本化机制总览lib/modules/versioning/index.md【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
