Renovate 集成 Rancher FleetBundle 定义与 GitRepo 清单的自动化依赖升级指南【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 内置的fleetmanager 用于解析并升级 Rancher Fleet 生态中的两类清单fleet.yamlBundle 定义与GitRepoGit 仓库引用YAML 清单。默认情况下它只处理带 Helm 引用的 bundle通过扩展managerFilePatterns可以覆盖到 GitRepo 更新配合registryAliases还能穿透内部镜像仓库的 pull-through 缓存直接查询上游源。读完本文你将掌握在 Renovate 中配置 fleet manager、精准控制匹配文件范围、以及借助 registry 别名打通内网私有仓库升级链路的完整方案。一、fleet manager 是什么能力边界与设计定位Renovate 的 fleet manager 位于 lib/modules/manager/fleet/index.ts官方定位是 Rancher Fleet 依赖管理器类别categories标记为cd与kubernetes即面向持续交付与 Kubernetes 场景。它支持三种数据源见 index.ts 中supportedDatasources声明数据源 ID用途git-tagsGitRepo 清单中spec.repo引用的 Git 仓库 tag 版本helmfleet.yaml中通过helm.repo引用的 Helm Chart 仓库dockerfleet.yaml中以oci://前缀引用的 OCI Helm Chart走 Docker 数据源manager 对外暴露两种依赖类型dep-types.ts也是你在 PR 和仪表盘中会看到的分类名fleetFleet 部署中的 Helm Chart 引用git_repoFleet GitRepo 清单中的 Git 仓库引用。也就是说fleet manager 同时承担Helm Chart 升级与Git 仓库 revision 升级两个职责二者的开启条件不同下文详述。二、默认行为只升级带 Helm 引用的 Bundle重要默认行为默认情况下只有带 Helm 引用的 bundle 才会被升级。这一默认值定义在 index.ts 的defaultConfig中export const defaultConfig { managerFilePatterns: [/(^|/)fleet\\.ya?ml/], };默认匹配模式/(^|/)fleet\.ya?ml/的含义是只匹配仓库中名为fleet.yaml或fleet.ymlya?ml中的?表示a可有可无的文件且文件可位于仓库根目录或任意子目录(^|/)表示路径起始处或目录分隔符之后。在这些文件里Renovate 会解析每个文档的helm:块识别 Chart 名称、仓库地址与版本号然后通过 Helm / Docker 数据源探测新版本并发起升级 PR。一个典型可被识别的fleet.yaml来自仓库测试夹具 valid_fleet.yamldefaultNamespace: cert-manager helm: chart: cert-manager repo: https://charts.jetstack.io releaseName: cert-manager version: v1.8.0 values: installCRDs: true --- defaultNamespace: external-dns helm: chart: oci://registry-1.docker.io/bitnamicharts/external-dns version: 7.1.2其中第一条走helm数据源第二条因 chart 以oci://开头会被判定为 OCI 镜像引用并改用docker数据源源码逻辑见 extract.ts 的isOCIRegistry判断以及getOciChartDep对 OCI 地址的解析。三、启用 GitRepo 更新扩展 managerFilePatterns如果你希望 Renovate 同时升级 GitRepo 清单中spec.revision指向的 Git tag就必须显式扩展managerFilePatterns配置把 GitRepo 清单文件纳入匹配范围。这是原文档给出的标准配置{ fleet: { managerFilePatterns: [/(^|/)fleet.ya?ml/, /myGitRepoManifests\\.yaml/] } }几点值得注意配置放在顶层fleet对象内属于按 manager 定向覆盖managerFilePatterns的写法默认的fleet.yaml匹配模式需要保留否则会连 Bundle 的升级一起关闭新增的/myGitRepoManifests\\.yaml/是示例正则实际使用时替换为你自己的 GitRepo 清单文件命名规则。正则中的\\.转义表示字面量.在 JSON 字符串中需要写成\\.避免点号被当作任意字符通配符一个更贴近实践的写法是匹配所有*.yaml中的 GitRepo 清单例如/(^|/)gitrepo\\.ya?ml/但注意该 manager 只会解析匹配文件中的 GitRepo 结构不会把普通 ConfigMap 等 K8s 资源误当成依赖。GitRepo 清单的典型形态见测试夹具 valid_gitrepo.yamlkind: GitRepo apiVersion: fleet.cattle.io/v1alpha1 metadata: name: my-repo namespace: fleet-local spec: repo: https://github.com/rancher/fleet-examples revision: v0.3.0 paths: - simple识别到这类清单后Renovate 将spec.repo作为依赖名与sourceUrl将spec.revision作为当前版本使用git-tags数据源git_repo依赖类型跟踪上游 Git 仓库的 tag 更新。对应提取逻辑见 extract.ts。四、registryAliases穿透内部镜像仓库的 pull-through 缓存在企业内网环境中集群往往通过内部 registry 配置 pull-through 缓存把上游 Chart 仓库/镜像仓库缓存到内网地址来访问外网制品。此时fleet.yaml中填写的repo是内网地址Renovate 直接查询内网地址可能拿不到完整的版本列表。为此 fleet manager 支持registryAliases当解析到helm.repo或 OCI chart 地址与某个别名完全匹配时会改用别名映射的真实上游地址去查询更新而 PR 中仍可保留内网地址不动。原文档给出的配置示例{ registryAliases: { https://registry.com/jetstack: https://charts.jetstack.io, registry.com/docker-io: registry-1.docker.io } }第一行是经典的 Chart 仓库别名fleet.yaml里写repo: https://registry.com/jetstack但 Renovate 用https://charts.jetstack.io查询版本第二行是针对 OCI 的别名oci://registry.com/docker-io/bitnamicharts/external-dns会被解析为使用registry-1.docker.io作为真实镜像源。该机制在 extract.ts 中的实现非常直接——先查别名表命中则用别名值作为registryUrls未命中则回退到清单中原始的repoconst alias config.registryAliases?.[doc.repo]; if (alias) { dep.registryUrls [alias]; } else { dep.registryUrls [doc.repo]; }配套的测试用例 extract.spec.ts 验证了两条路径HTTPS 仓库别名映射后registryUrls变为[https://charts.jetstack.io]OCI 别名映射后depName保留内网前缀registry.com/docker-io/bitnamicharts/external-dns而packageName被改写为真实上游registry-1.docker.io/bitnamicharts/external-dns。五、源码级解析流程schema 校验与 skipReason 分支fleet manager 的解析入口是extractPackageFileextract.ts整体流程为先用正则fleet.ya?ml判断当前文件名是 Bundle 定义还是 GitRepo 清单走不同解析分支使用parseYaml并传入 zod 自定义 schemaFleetFile或GitRepofailureBehaviour: filter意味着无法通过 schema 校验的文档会被过滤掉避免整份文件解析失败对每个文档提取依赖若最终一个依赖都没提取到则返回null表示该文件无需处理。5.1 zod schema 定义了可识别的字段白名单lib/modules/manager/fleet/schema.ts 中的两个 schema 决定了哪些字段会被读取FleetFile读取顶层helm块含chart、repo、version、releaseName与可选的targetCustomizations数组每项含name与helm覆盖块GitRepo读取metadata.name、kind与spec.repo、spec.revision。这意味着fleet.yaml中的values、defaultNamespace等其他字段虽然原样保留在文件里但不会被 Renovate 当作升级依据仅helm块参与依赖提取。5.2 各类跳过场景skipReason当清单信息不完整时Renovate 不会报错而是给该依赖打上skipReason标记并跳过升级。从 extract.ts 与测试 extract.spec.ts 可归纳出以下分支场景skipReason触发条件缺少 chart 名missing-depnamehelm.chart为空缺少仓库地址no-repositoryhelm.repo为空非 OCI 且 chart 名不是本地路径本地 Chartlocal-chartchart 名形如./charts/example的本地路径无需也不应升级缺少版本unspecified-versionhelm.version或spec.revision为空GitRepo 缺 repomissing-depnamespec.repo为空测试夹具 invalid_fleet.yaml 与 invalid_gitrepo.yaml 分别覆盖了上述场景例如缺少repo的 GitRepo 清单会被标记missing-depname只有repo而没有revision的会被标记unspecified-version。5.3 targetCustomizations一个 bundle 拆出多个依赖Fleet 的targetCustomizations允许针对不同集群覆盖 helm 参数例如不同集群使用不同版本。fleet manager 会为每个 customization 单独生成一个依赖从而让版本差异较大的目标集群各自得到独立的升级 PR。其实现策略extract.ts先基于全局helm块生成一个依赖对每个targetCustomizations[i]把全局 helm 块与该 customization 的helm覆盖合并浅合并customization 中的字段优先再提取一次生成的依赖depName使用 customization 的name未提供name时回退为targetCustomization[0]这类索引名目的是让每个 customization 的 PR 可以独立拆分合并时会删掉全局块中的version若某 customization 未显式指定version说明它依赖全局变量注入版本则不为其创建升级 PR标记unspecified-version跳过避免用错误的版本号发起无效 PR。测试 extract.spec.ts 验证了一个全局块 一个带version: v1.9.2的 customization能产出两个不同currentValue的依赖以及customization 未覆盖 version 时生成一个跳过依赖的行为。六、如何验证与调试本地跑通提取逻辑如果你想确认某份fleet.yaml或 GitRepo 清单能被正确识别可以直接运行仓库中针对该 manager 的单元测试pnpm jest lib/modules/manager/fleet测试覆盖了空内容、畸形 YAML、合法/非法 Bundle、合法/非法 GitRepo、registryAliases 映射、OCI 无版本跳过、targetCustomizations 拆分等全部关键路径见 extract.spec.ts是理解该 manager 行为的权威参考。在真实仓库中接入后Renovate 运行日志中的depType: fleet/depType: git_repo以及各类skipReason信息也可以帮你快速定位清单为何未被升级。七、完整接入示例一份可直接落地的配置综合以上要点一份同时管理 Bundle 与 GitRepo、且打通内网缓存的完整配置如下{ fleet: { managerFilePatterns: [ /(^|/)fleet.ya?ml/, /(^|/)gitrepo\\.ya?ml/ ], registryAliases: { https://registry.com/jetstack: https://charts.jetstack.io, https://registry.com/prometheus-community: https://prometheus-community.github.io/helm-charts, registry.com/docker-io: registry-1.docker.io } } }落地建议范围最小化GitRepo 匹配正则尽量贴合你的实际命名如gitrepo\\.ya?ml避免把不含依赖的 YAML 也扫进来增加无效任务别名按需维护只在确认内网地址无法直接查询上游时才配置registryAliases若内网 registry 本身提供完整版本列表则无需别名关注 skipReason升级 PR 迟迟不出现时优先检查清单是否命中上表任一跳过场景多数情况下补全version/repo/revision字段即可恢复升级。至此Renovate 的 fleet manager 已能覆盖 Rancher Fleet 生态中最常见的两类依赖升级诉求Helm Chart含 OCI 形态与 GitRepo revision并通过managerFilePatterns与registryAliases两个配置旋钮适配各种私有化部署拓扑。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考