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），僅供參考