Renovate Argo CD Manager 实战指南配置 managerFilePatterns、提取依赖与 OCI Helm Chart 更新【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateArgo CD 是 Kubernetes 生态中最流行的 GitOps 持续交付工具之一其Application/ApplicationSet清单中的repoURL、targetRevision、chart与kustomize.images等字段承载着大量待升级的依赖信息。Renovate 通过内置的argocdmanager 自动扫描这些清单并生成升级 Pull Request。本篇技术指南以仓库内 lib/modules/manager/argocd/readme.md 为核心结合 manager 的源码与测试用例完整讲解如何配置managerFilePatterns、理解依赖提取规则以及处理 OCI Helm Chart 的更新方案。为什么 Argo CD manager 没有默认的文件匹配模式与大多数 manager如dockerfile默认匹配Dockerfile、github-actions默认匹配.github/workflows/*.yml不同argocdmanager 的默认managerFilePatterns为空数组。这一设计在 lib/modules/manager/argocd/index.ts 中有直接体现export const defaultConfig { managerFilePatterns: [], };原因在于Argo CD 的 YAML 清单没有统一的文件名或目录命名约定。Application/ApplicationSet可以出现在argocd/目录、apps/目录、仓库根目录甚至与普通 Kubernetes 清单混放在一起。如果 Renovate 为argocdmanager 硬编码一个默认匹配模式就必须在仓库中逐个检查每个*.yaml文件是否包含 Argo CD 定义既浪费资源又容易误伤无关清单。因此使用argocdmanager 的第一步就是在 Renovate 配置中显式指定managerFilePatterns让 Renovate 只扫描真正包含 Argo CD 定义的 YAML 文件。配置 managerFilePatterns三种典型场景managerFilePatterns是 Renovate 的通用配置项类型为字符串数组支持 RegExre2与 glob 模式见 lib/config/options/index.ts 中的定义。以下三种场景覆盖了最常见的仓库布局。场景一仓库中大多数 .yaml 文件都是 Argo CD 清单如果仓库以 GitOps 为主绝大多数 YAML 都属于 Argo CD可以匹配所有 YAML 文件{ argocd: { managerFilePatterns: [/\\.yaml$/] } }正则用/包裹\\.yaml$匹配以.yaml结尾的路径。注意这里不匹配.yml结尾的文件如有需要可写成/\\.ya?ml$/。场景二Argo CD 清单集中在 argocd/ 目录如果仓库专门用argocd/目录存放 GitOps 清单可以缩小范围{ argocd: { managerFilePatterns: [/argocd/.\\.yaml$/] } }argocd/.要求路径中包含argocd/前缀\\.yaml$限定文件后缀argocd/子目录下的嵌套文件同样能命中。场景三只有一个 Argo CD 文件如果清单高度集中甚至可以精确到单个文件{ argocd: { managerFilePatterns: [/^config/applications\\.yaml$/] } }^锚定路径起点$锚定终点整条模式只匹配config/applications.yaml这一个文件。文件筛选与解析从 apiVersion 到依赖列表配置好managerFilePatterns之后Renovate 会对命中的文件调用extractPackageFile()。整个提取流程分为三步第一步通过 apiVersion 快速过滤为避免解析无关 YAMLlib/modules/manager/argocd/util.ts 定义了一个预检测正则// looks for apiVersion: argoproj.io/ with optional quoting of the value export const fileTestRegex regEx(/\s*apiVersion:\s*??argoproj.io\//);只有文件中出现apiVersion: argoproj.io/支持单引号、双引号或不加引号时才会继续处理否则直接跳过并记录 debug 日志。测试用例 lib/modules/manager/argocd/extract.spec.ts 验证了双引号与单引号两种写法都能正常命中而普通的 Kubernetes manifest不含argoproj.ioapiVersion会被返回null。第二步Zod 模式校验与多文档解析通过预检测后lib/modules/manager/argocd/schema.ts 用 Zod v4 定义了严格的结构模式Applicationkind必须为字面量Applicationspec.source/spec.sources可选ApplicationSetkind必须为字面量ApplicationSet依赖信息位于spec.template.spec.source/spec.template.spec.sourcesApplicationSource包含chart可选、repoURL、targetRevision、kustomize.images可选。解析使用multidocYaml支持一个文件内多个---分隔的文档且removeTemplates: true会在提取阶段剥离 Helm 模板语法如{{ .Values.chart }}。如果整个文件没有任何有效依赖例如 malformedApplications.yml 中缺少 source 或 sources 为空的清单extractPackageFile()返回null。第三步按 source 类型分发提取lib/modules/manager/argocd/extract.ts 的processSource()根据source字段组合决定使用哪个 datasource并生成PackageDependency列表。processAppSpec()会同时处理spec.source单个与spec.sources数组两种写法对于ApplicationSet则从spec.template.spec中读取同样的字段。依赖提取规则Helm、Git 与 Kustomize 镜像根据source中chart字段与repoURL协议的不同argocdmanager 会走三条不同的提取路径。经典 Helm ChartHTTP/HTTPS/GS 仓库当source.chart存在且repoURL带显式协议如https://、gs://时依赖走helmdatasourceapiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: kube-state-metrics repoURL: https://prometheus-community.github.io/helm-charts targetRevision: 2.4.1提取结果为datasource: helm、depName: kube-state-metrics、registryUrls: [https://prometheus-community.github.io/helm-charts]当前版本为targetRevision: 2.4.1。测试用例 lib/modules/manager/argocd/extract.spec.ts 的第 3587 行完整验证了这一行为。不带协议或 OCI 协议的仓库按 OCI Helm Chart 处理当repoURL不含://如somecontainer.registry.io或显式以oci://开头时Renovate 将其视为 OCI 注册表交给dockerdatasource 处理apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: some/image repoURL: somecontainer.registry.io targetRevision: 1.2.0提取逻辑复用自 Helm v3 manager 的 lib/modules/manager/helmv3/oci.tsremoveOCIPrefix()去掉oci://前缀trimTrailingSlash()清理末尾斜杠最终depName形如registry.example.com/charts/some/chart并设置pinDigests: false因为 Helm 的 OCI 引用chartsha256:...不能与 semver 版本同时使用。Git 仓库 Kustomize 镜像覆盖当source.chart不存在且repoURL是普通 Git 地址时主依赖走git-tagsdatasource如果同时配置了kustomize.images其中image...形式的每一项会被拆解为独立的dockerdatasource 依赖apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: repoURL: https://git.example.com/foo/bar.git targetRevision: v1.2.0 kustomize: images: - someImagesomecontainer.registry.io/someContainer:v2.3.4正则(?image.)$截取等号右侧的镜像引用再通过getDep()来自 lib/modules/manager/dockerfile/extract.ts解析为docker依赖。合法的镜像引用会生成autoReplaceStringTemplate与replaceString便于 Renovate 在 PR 中精确替换原始字符串而缺少合法镜像的部分如notActuallyValidAndShouldBeIgnored会被静默忽略——这一行为在 validApplication.yml 与extract.spec.ts的full test中有完整验证。支持的 datasource 一览argocdmanager 在 lib/modules/manager/argocd/index.ts 中声明了全部受支持的 datasourcedatasource适用场景dockerOCI Helm Chartoci://或无协议仓库、Kustomize 镜像覆盖git-tags指向 Git 仓库的source.repoURLhelm经典 Helm Chart 仓库HTTPS、GS 等带协议地址对应地manager 的分类categories为kubernetes与cddisplayName 为Argo CD。OCI Helm ChartsregistryAliases 的用法Renovate 使用dockerdatasource 查询 OCI 注册表中的 Helm Chart。对于需要把某个注册表主机映射到另一个查询地址的场景例如使用 pull-through 缓存镜像站可以通过registryAliases配置映射{ argocd: { managerFilePatterns: [/argocd/.\\.yaml$/] }, registryAliases: { registry.example.com: registry-1.docker.io } }对应的 Argo CD 清单apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: some/chart repoURL: oci://registry.example.com/charts targetRevision: 1.0.0提取结果中depName保持为清单中的原始地址registry.example.com/charts/some/chart而packageName被替换为registry-1.docker.io/charts/some/chart即 Renovate 实际去查询的地址。测试用例resolves registryAliases for OCI chartslib/modules/manager/argocd/extract.spec.ts精确验证了该映射行为。registryAliases在extractPackageFile()中通过配置参数传入processSource()进而传给getOciChartDep()——这与容器镜像引用的 registry 别名解析机制完全一致。版本格式调整如果需要对提取出的依赖调整版本格式例如 Helm Chart 的版本、Git tag 的版本请参考 versioning 模块文档为对应 datasource 或 manager 配置合适的versioning策略如semver、helm等。argocdmanager 本身不强制版本格式而是把targetRevision原样作为currentValue交给 datasource 与 versioning 层处理。小结argocdmanager 没有默认文件匹配模式必须通过managerFilePatterns显式声明要扫描的 YAML 文件文件级过滤依赖apiVersion: argoproj.io/预检测正则随后由 Zod 模式解析Application/ApplicationSet含多文档与 Helm 模板剥离依赖提取遵循三条规则带协议的仓库走helmdatasource、oci://或无协议仓库走dockerdatasource、Git 仓库走git-tagsdatasource 并可附加解析kustomize.imagesOCI Helm Chart 默认由dockerdatasource 查询可用registryAliases把仓库主机映射到 pull-through 缓存等实际查询地址。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Renovate Argo CD Manager 实战指南配置 managerFilePatterns、提取依赖与 OCI Helm Chart 更新【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateArgo CD 是 Kubernetes 生态中最流行的 GitOps 持续交付工具之一其Application/ApplicationSet清单中的repoURL、targetRevision、chart与kustomize.images等字段承载着大量待升级的依赖信息。Renovate 通过内置的argocdmanager 自动扫描这些清单并生成升级 Pull Request。本篇技术指南以仓库内 lib/modules/manager/argocd/readme.md 为核心结合 manager 的源码与测试用例完整讲解如何配置managerFilePatterns、理解依赖提取规则以及处理 OCI Helm Chart 的更新方案。为什么 Argo CD manager 没有默认的文件匹配模式与大多数 manager如dockerfile默认匹配Dockerfile、github-actions默认匹配.github/workflows/*.yml不同argocdmanager 的默认managerFilePatterns为空数组。这一设计在 lib/modules/manager/argocd/index.ts 中有直接体现export const defaultConfig { managerFilePatterns: [], };原因在于Argo CD 的 YAML 清单没有统一的文件名或目录命名约定。Application/ApplicationSet可以出现在argocd/目录、apps/目录、仓库根目录甚至与普通 Kubernetes 清单混放在一起。如果 Renovate 为argocdmanager 硬编码一个默认匹配模式就必须在仓库中逐个检查每个*.yaml文件是否包含 Argo CD 定义既浪费资源又容易误伤无关清单。因此使用argocdmanager 的第一步就是在 Renovate 配置中显式指定managerFilePatterns让 Renovate 只扫描真正包含 Argo CD 定义的 YAML 文件。配置 managerFilePatterns三种典型场景managerFilePatterns是 Renovate 的通用配置项类型为字符串数组支持 RegExre2与 glob 模式见 lib/config/options/index.ts 中的定义。以下三种场景覆盖了最常见的仓库布局。场景一仓库中大多数 .yaml 文件都是 Argo CD 清单如果仓库以 GitOps 为主绝大多数 YAML 都属于 Argo CD可以匹配所有 YAML 文件{ argocd: { managerFilePatterns: [/\\.yaml$/] } }正则用/包裹\\.yaml$匹配以.yaml结尾的路径。注意这里不匹配.yml结尾的文件如有需要可写成/\\.ya?ml$/。场景二Argo CD 清单集中在 argocd/ 目录如果仓库专门用argocd/目录存放 GitOps 清单可以缩小范围{ argocd: { managerFilePatterns: [/argocd/.\\.yaml$/] } }argocd/.要求路径中包含argocd/前缀\\.yaml$限定文件后缀argocd/子目录下的嵌套文件同样能命中。场景三只有一个 Argo CD 文件如果清单高度集中甚至可以精确到单个文件{ argocd: { managerFilePatterns: [/^config/applications\\.yaml$/] } }^锚定路径起点$锚定终点整条模式只匹配config/applications.yaml这一个文件。文件筛选与解析从 apiVersion 到依赖列表配置好managerFilePatterns之后Renovate 会对命中的文件调用extractPackageFile()。整个提取流程分为三步第一步通过 apiVersion 快速过滤为避免解析无关 YAMLlib/modules/manager/argocd/util.ts 定义了一个预检测正则// looks for apiVersion: argoproj.io/ with optional quoting of the value export const fileTestRegex regEx(/\s*apiVersion:\s*??argoproj.io\//);只有文件中出现apiVersion: argoproj.io/支持单引号、双引号或不加引号时才会继续处理否则直接跳过并记录 debug 日志。测试用例 lib/modules/manager/argocd/extract.spec.ts 验证了双引号与单引号两种写法都能正常命中而普通的 Kubernetes manifest不含argoproj.ioapiVersion会被返回null。第二步Zod 模式校验与多文档解析通过预检测后lib/modules/manager/argocd/schema.ts 用 Zod v4 定义了严格的结构模式Applicationkind必须为字面量Applicationspec.source/spec.sources可选ApplicationSetkind必须为字面量ApplicationSet依赖信息位于spec.template.spec.source/spec.template.spec.sourcesApplicationSource包含chart可选、repoURL、targetRevision、kustomize.images可选。解析使用multidocYaml支持一个文件内多个---分隔的文档且removeTemplates: true会在提取阶段剥离 Helm 模板语法如{{ .Values.chart }}。如果整个文件没有任何有效依赖例如 malformedApplications.yml 中缺少 source 或 sources 为空的清单extractPackageFile()返回null。第三步按 source 类型分发提取lib/modules/manager/argocd/extract.ts 的processSource()根据source字段组合决定使用哪个 datasource并生成PackageDependency列表。processAppSpec()会同时处理spec.source单个与spec.sources数组两种写法对于ApplicationSet则从spec.template.spec中读取同样的字段。依赖提取规则Helm、Git 与 Kustomize 镜像根据source中chart字段与repoURL协议的不同argocdmanager 会走三条不同的提取路径。经典 Helm ChartHTTP/HTTPS/GS 仓库当source.chart存在且repoURL带显式协议如https://、gs://时依赖走helmdatasourceapiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: kube-state-metrics repoURL: https://prometheus-community.github.io/helm-charts targetRevision: 2.4.1提取结果为datasource: helm、depName: kube-state-metrics、registryUrls: [https://prometheus-community.github.io/helm-charts]当前版本为targetRevision: 2.4.1。测试用例 lib/modules/manager/argocd/extract.spec.ts 的第 3587 行完整验证了这一行为。不带协议或 OCI 协议的仓库按 OCI Helm Chart 处理当repoURL不含://如somecontainer.registry.io或显式以oci://开头时Renovate 将其视为 OCI 注册表交给dockerdatasource 处理apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: some/image repoURL: somecontainer.registry.io targetRevision: 1.2.0提取逻辑复用自 Helm v3 manager 的 lib/modules/manager/helmv3/oci.tsremoveOCIPrefix()去掉oci://前缀trimTrailingSlash()清理末尾斜杠最终depName形如registry.example.com/charts/some/chart并设置pinDigests: false因为 Helm 的 OCI 引用chartsha256:...不能与 semver 版本同时使用。Git 仓库 Kustomize 镜像覆盖当source.chart不存在且repoURL是普通 Git 地址时主依赖走git-tagsdatasource如果同时配置了kustomize.images其中image...形式的每一项会被拆解为独立的dockerdatasource 依赖apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: repoURL: https://git.example.com/foo/bar.git targetRevision: v1.2.0 kustomize: images: - someImagesomecontainer.registry.io/someContainer:v2.3.4正则(?image.)$截取等号右侧的镜像引用再通过getDep()来自 lib/modules/manager/dockerfile/extract.ts解析为docker依赖。合法的镜像引用会生成autoReplaceStringTemplate与replaceString便于 Renovate 在 PR 中精确替换原始字符串而缺少合法镜像的部分如notActuallyValidAndShouldBeIgnored会被静默忽略——这一行为在 validApplication.yml 与extract.spec.ts的full test中有完整验证。支持的 datasource 一览argocdmanager 在 lib/modules/manager/argocd/index.ts 中声明了全部受支持的 datasourcedatasource适用场景dockerOCI Helm Chartoci://或无协议仓库、Kustomize 镜像覆盖git-tags指向 Git 仓库的source.repoURLhelm经典 Helm Chart 仓库HTTPS、GS 等带协议地址对应地manager 的分类categories为kubernetes与cddisplayName 为Argo CD。OCI Helm ChartsregistryAliases 的用法Renovate 使用dockerdatasource 查询 OCI 注册表中的 Helm Chart。对于需要把某个注册表主机映射到另一个查询地址的场景例如使用 pull-through 缓存镜像站可以通过registryAliases配置映射{ argocd: { managerFilePatterns: [/argocd/.\\.yaml$/] }, registryAliases: { registry.example.com: registry-1.docker.io } }对应的 Argo CD 清单apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: chart: some/chart repoURL: oci://registry.example.com/charts targetRevision: 1.0.0提取结果中depName保持为清单中的原始地址registry.example.com/charts/some/chart而packageName被替换为registry-1.docker.io/charts/some/chart即 Renovate 实际去查询的地址。测试用例resolves registryAliases for OCI chartslib/modules/manager/argocd/extract.spec.ts精确验证了该映射行为。registryAliases在extractPackageFile()中通过配置参数传入processSource()进而传给getOciChartDep()——这与容器镜像引用的 registry 别名解析机制完全一致。版本格式调整如果需要对提取出的依赖调整版本格式例如 Helm Chart 的版本、Git tag 的版本请参考 versioning 模块文档为对应 datasource 或 manager 配置合适的versioning策略如semver、helm等。argocdmanager 本身不强制版本格式而是把targetRevision原样作为currentValue交给 datasource 与 versioning 层处理。小结argocdmanager 没有默认文件匹配模式必须通过managerFilePatterns显式声明要扫描的 YAML 文件文件级过滤依赖apiVersion: argoproj.io/预检测正则随后由 Zod 模式解析Application/ApplicationSet含多文档与 Helm 模板剥离依赖提取遵循三条规则带协议的仓库走helmdatasource、oci://或无协议仓库走dockerdatasource、Git 仓库走git-tagsdatasource 并可附加解析kustomize.imagesOCI Helm Chart 默认由dockerdatasource 查询可用registryAliases把仓库主机映射到 pull-through 缓存等实际查询地址。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
宏详解)
