Renovate Glasskube Manager 使用指南为 Glasskube Packages 配置依赖提取与版本更新【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本文是 Renovate CLI项目仓库根目录中glasskubemanager 的实战指南核心围绕 Glasskube manager 官方说明 展开。Glasskube 是面向 Kubernetes 的开源包管理器其 YAML 资源文件Package、ClusterPackage、PackageRepository需要纳入 Renovate 的依赖自动化流程。读完本文你将掌握为什么glasskubemanager 必须自定义managerFilePatterns、如何正确配置它、资源文件中的版本与仓库数据如何被提取以及底层数据源如何查询可用版本。Glasskube 与 Renovate 的集成方式Glasskube 通过自定义资源CRD管理 Kubernetes 集群中的应用安装其核心资源类型有三类而 Renovate 的glasskubemanager 恰好围绕这三类资源工作Package/ClusterPackage声明要安装的包及其版本是 Renovate 提取版本数据的对象PackageRepository声明包仓库registry的地址用于确定从哪里查询可用版本。按 index.ts 中的定义该 manager 的类别为kubernetes和cd持续交付唯一支持的 data source 是glasskube-packages见supportedDatasources与 GlasskubePackagesDatasource。也就是说glasskubemanager 只负责从 YAML 中“读出”依赖真正查版本、算更新靠的是配套的glasskube-packages数据源。核心配置为什么必须自定义 managerFilePatternsglasskubemanager 最特别的一点在官方说明中写得很直白使用glasskubemanager 时你必须设置自己的managerFilePatterns模式。该 manager 没有默认的managerFilePatterns因为 Glasskube YAML 文件没有通用的文件名或目录名约定。这与大多数 manager 不同。像dockerfile、github-actions这类 manager 都有内置的默认文件名匹配规则而 Glasskube 资源可能被放在任意命名的 YAML 文件中无法猜测。查看 index.ts 的defaultConfig可以印证这一点export const defaultConfig { managerFilePatterns: [], };默认是空数组意味着不配置就永远不会被触发。managerFilePatterns这一配置项在 config 选项定义 中说明为用于匹配 manager 文件的re2正则表达式和 glob 模式类型为字符串数组allowString也可传单个字符串属于仓库阶段stage: repository配置且仅能通过配置文件设置cli: false、env: false。手动配置managerFilePatterns还有一个现实收益它能让 Renovate 跳过仓库中每一个*.yaml文件的逐一检查。否则为了识别 Glasskube 定义每个 YAML 文件都要被解析一遍拖慢仓库扫描。配置示例最小可运行配置在renovate.json中为glasskubemanager 指定文件匹配模式例如约定所有 Glasskube 资源都放在glasskube/目录下{ managerFilePatterns: { glasskube: [glasskube/**/*.yaml, glasskube/**/*.yml] } }如果你遵循某些约定例如固定文件名也可以写得更窄{ managerFilePatterns: { glasskube: [**/packages.yaml] } }managerFilePatterns支持re2正则与 glob 两种写法。它的取值按 manager 名分组因此配置项中的键名必须是glasskube详见 config 选项定义。配置完成后Renovate 只会在命中这些模式的文件中寻找 Glasskube 资源定义。支持的资源结构与字段glasskubemanager 用 Zod 模式对 YAML 进行校验解析定义见 schema.tsPackage / ClusterPackage{ apiVersion: string, // 必须以 packages.glasskube.dev/ 开头 kind: Package | ClusterPackage, spec: { packageInfo: { name: string, // 包名对应 depName version: string, // 当前版本对应 currentValue repositoryName?: string // 可选的仓库名用于定位 PackageRepository } } }PackageRepository{ apiVersion: string, // 必须以 packages.glasskube.dev/ 开头 kind: PackageRepository, metadata: { name: string, // 仓库名供 Package 引用 annotations?: Recordstring, string // 可含默认仓库标记 }, spec: { url: string // 仓库地址成为 registryUrls } }注意两点限制apiVersion必须严格以packages.glasskube.dev/开头否则该资源会被过滤掉failureBehaviour: filter只有Package、ClusterPackage、PackageRepository三种kind会被识别其余资源被静默忽略。仓库中附带的真实示例 package-and-repo.yaml 展示了标准写法apiVersion: packages.glasskube.dev/v1alpha1 kind: PackageRepository metadata: annotations: packages.glasskube.dev/default-repository: true name: glasskube spec: url: https://packages.dl.glasskube.dev/packages --- apiVersion: packages.glasskube.dev/v1alpha1 kind: PackageRepository metadata: name: local spec: url: http://localhost:9090/packages --- apiVersion: packages.glasskube.dev/v1alpha1 kind: ClusterPackage metadata: name: argo-cd spec: packageInfo: name: argo-cd repositoryName: glasskube version: v2.11.71这里演示了三种典型情况带默认仓库注解的官方仓库、普通本地仓库、以及显式引用glasskube仓库的ClusterPackage。提取原理从 YAML 到依赖对象glasskubemanager 的提取逻辑集中在 extract.ts整体分两步。第一步解析资源parseResources对每个命中的文件调用parseYaml(content, { customSchema: GlasskubeResource, failureBehaviour: filter })支持单个 YAML 文件内用---分隔多个文档与上面的示例一致。随后按kind分类ClusterPackage/Package→ 收集进packages列表PackageRepository→ 收集进repositories列表。第二步解析依赖resolvePackageDependencies对每个 package 构造一个PackageDependencydepName←spec.packageInfo.namecurrentValue←spec.packageInfo.versiondatasource←glasskube-packagesregistryUrls← 由仓库解析得出见下一节。PackageDependency是 Renovate 管理器的统一产物类型见 manager 公共类型后续版本查找、更新计算、PR 生成都基于它进行。仓库解析规则与 unknown-registryregistryUrls的确定是核心逻辑之一由findRepository实现显式引用若spec.packageInfo.repositoryName有值则与各PackageRepository的metadata.name精确匹配匹配成功后使用其spec.url默认仓库若repositoryName为空或缺失则查找带有注解packages.glasskube.dev/default-repository: true的PackageRepository作为默认仓库无法匹配两种情况都不满足时依赖会被标记skipReason: unknown-registry表示无法确定包来源该依赖不会参与更新。测试用例 extract.spec.ts 覆盖了这些分支显式repositoryName提取出https://packages.dl.glasskube.dev/packages缺失仓库时产出skipReason: unknown-registryrepositoryName为空字符串或缺省时回落到默认仓库。单文件与多文件提取的差异glasskubemanager 同时实现了两个提取入口见 index.ts 的导出extractPackageFile单文件提取仓库解析范围仅限于当前文件内定义的PackageRepositoryextractAllPackageFiles批量提取会先遍历所有命中的文件把全部PackageRepository汇总到allRepositories再统一解析所有 package。这意味着PackageRepository 和 Package 可以分散在不同的 YAML 文件中只要都被managerFilePatterns覆盖即可。这一点对配置实践很重要如果你的仓库中包声明与仓库声明分文件管理务必保证两类文件都命中模式否则跨文件的仓库引用可能解析失败。测试中的 “extract registryUrl from repo in other file” 场景正是验证了这种跨文件解析能力。配套数据源glasskube-packages 如何查版本提取出的依赖最终交给 GlasskubePackagesDatasource 查询可用版本其工作方式如下默认仓库地址为https://packages.dl.glasskube.dev/packages并开启自定义仓库支持customRegistrySupport true因此提取阶段得到的registryUrls会覆盖默认值版本列表请求{registryUrl}/{packageName}/versions.yaml解析出latestVersion与versions[]schema 见 数据源 schema元数据再请求{registryUrl}/{packageName}/{latestVersion}/package.yaml从references中识别label为github的地址作为sourceUrl用于生成更新日志website作为homepage默认版本方案是glasskube版本化模块defaultVersioning用于对v2.11.71这类带构建元数据的版本做比较排序请求结果带有缓存withCache减少重复网络请求。验证与调试仓库自带两套测试来保障该 manager 的行为可作为调试参照extract.spec.ts验证单文件提取结果、空文件列表返回null、未知仓库的unknown-registry跳过、跨文件仓库解析、默认仓库回落等行为数据源侧测试 glasskube-packages/index.spec.ts 配合versions.yaml、package.yaml等 fixture 验证版本与元数据解析。本地验证时可用pnpm jest运行对应用例或直接用renovate-config-validator校验你的managerFilePatterns配置格式是否正确。注意事项与限制必须配置managerFilePatterns否则 manager 不生效默认空数组意味着零匹配这是与大多数 manager 最本质的差异匹配范围要覆盖两类资源Package/ClusterPackage与PackageRepository若分文件存放所有相关文件都要落入匹配模式且跨文件解析依赖extractAllPackageFiles批量入口apiVersion前缀校验严格非packages.glasskube.dev/前缀的资源会被直接过滤无法定位仓库的包会被跳过表现为skipReason: unknown-registry更新 PR 不会生成可通过补充repositoryName或默认仓库注解解决本文所有配置示例基于当前仓库代码manager 实现见 extract.ts数据源见 glasskube-packages 目录实际使用时请以你所用 Renovate 版本为准。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考