Renovate 的 endoflife-date 数据源：基于软件生命周期自动化更新版本

Renovate 的 endoflife-date 数据源基于软件生命周期自动化更新版本【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本篇技术指南讲解 Renovate 中endoflife-date数据源lib/modules/datasource/endoflife-date/的完整用法它借助 endoflife.date 提供的软件版本与生命周期终止End-of-Life信息为那些没有传统包仓库的软件如 Amazon EKS、操作系统发行版等提供版本追踪能力。读完本文你将掌握如何用自定义正则 Manager 把任意.tfvars等配置文件中的版本字段接入 Renovate 更新流程并理解该数据源的底层请求、数据解析与废弃标记机制。一、数据源是什么用 EOL 信息驱动的版本追踪endoflife-date数据源的核心思路很简单很多软件并不发布在 npm、Maven 或 Docker Hub 这类传统注册表里它们的版本演进与支持周期信息反而被整理在 endoflife.date 这个公开网站上。Renovate 通过该网站的公开 API 读取某个软件如amazon-eks的版本列表从而把版本更新自动化能力延伸到这些没有包管理器的场景。在仓库中该数据源的标识与默认注册表地址定义在 lib/modules/datasource/endoflife-date/common.tsexport const registryUrl https://endoflife.date/api; export const datasource endoflife-date;这意味着在配置中只需写datasourceendoflife-dateRenovate 就会向该 API 发起查询。对应的数据源实现类是EndoflifeDateDatasourcelib/modules/datasource/endoflife-date/index.ts它继承了统一的Datasource抽象基类lib/modules/datasource/datasource.ts对外暴露标准的getReleases()接口。二、底层工作原理请求、解析与缓存1. 请求路径构造当 Renovate 需要查询某个软件时会调用_getReleases()通过joinUrlParts拼接出最终的 API 路径const url joinUrlParts(registryUrl, ${packageName}.json);也就是说depNameamazon-eks最终会被解析为对https://endoflife.date/api/amazon-eks.json的 GET 请求。因此depName 必须与 endoflife.date 站内登记的软件名称package 名称完全一致。如果你不确定某个软件在 endoflife.date 上的确切名称可以使用该网站 API 文档中提供的 All packages全部软件包端点来查询可用清单。2. 响应数据解析Zod Schema 与废弃标记API 返回的是 JSON 数组每一项代表一个版本周期cycle。数据源用 Zod schemalib/modules/datasource/endoflife-date/schema.ts进行校验和转换const ExpireableField z.union([ UtcDate.transform((x) { const now DateTime.now().toUTC(); return x now; // 日期型 EOL若已过期则视为废弃 }), z.boolean(), // 布尔型 EOL / discontinued ]); export const EndoflifeDateVersions z .object({ cycle: z.string(), latest: z.optional(z.string()), releaseDate: MaybeTimestamp, eol: z.optional(ExpireableField), discontinued: z.optional(ExpireableField), }) .transform(({ cycle, latest, releaseDate, eol, discontinued }): Release { const version latest ?? cycle; const isDeprecated eol true || discontinued true; return { version, releaseTimestamp, isDeprecated }; }) .array();从这段源码可以提炼出几个关键事实版本号取值优先取latest字段若不存在则回退到cycle版本周期名。例如 Amazon EKS 数据中cycle为1.26、latest为1.26-eks-1最终版本号取1.26-eks-1。发布时间的来源releaseDate字段被映射为releaseTimestamp。数据源在类声明中标注了releaseTimestampSupport true并在releaseTimestampNote中说明发布时间的确定来自结果中的releaseDate字段。这意味着 Renovate 可以基于该时间戳应用最小发布时间minimum release age等策略。废弃判断eol与discontinued字段既可能是布尔值也可能是日期字符串。日期会被与当前 UTC 时间比较若 EOL 日期已过该版本被视为已废弃deprecated。这一逻辑在测试中得到了充分验证详见下文第五节。3. 默认行为与缓存EndoflifeDateDatasource还声明了这些默认行为lib/modules/datasource/endoflife-date/index.ts属性值含义defaultRegistryUrls[https://endoflife.date/api]默认注册表地址defaultVersioningloose默认使用宽松版本控制cachingtrue结果可被包缓存复用releaseTimestampSupporttrue支持基于发布日期的时间策略getReleases()外层还套了一层withCache包缓存缓存键为registryUrl:packageName的组合这保证了同一仓库中多次查询同一个软件时不会重复请求 API。而错误处理走的是基类handleGenericErrorslib/modules/datasource/datasource.ts遇到 429 限流或 5xx 服务端错误会包装成ExternalHostError抛出404 与空结果则直接返回null表示查无此包。三、版本控制默认 loose推荐 semver原文档明确提醒该数据源默认使用loose版本控制。loose是 Renovate 中最宽松的版本方案几乎任何字符串形式都能被解析适合像1.26-eks-1、3这类非标准版本号。但宽松也意味着排序和比较规则简单粗暴。因此官方文档建议只要可能就改用更严格的版本方案如semver以获得更准确的升级判断。你可以在renovate.json的packageRules中用matchVersioning或在自定义 Manager 的versioningTemplate中为特定包指定更严格的版本控制。仓库中endoflife-date的测试lib/modules/datasource/endoflife-date/index.spec.ts使用的也是默认的 loose 解析。四、实战配置用自定义 Manager 更新 Terraform.tfvars中的版本原文档给出了一个完整的端到端示例这是本数据源最典型的应用场景使用 Amazon EKS 时让 Renovate 自动更新 Terraform.tfvars文件里的 Kubernetes 版本号。1. 在.tfvars文件中标记要更新的变量假设你的仓库里有这样一个.tfvars文件其中kubernetes_version定义了 EKS 使用的 Kubernetes 版本# renovate: datasourceendoflife-date depNameamazon-eks versioningloose kubernetes_version 1.26注意紧挨着变量的这行注释# renovate: datasourceendoflife-date depNameamazon-eks versioningloose。它相当于给 Renovate 下达指令——用endoflife-date数据源、查询amazon-eks这个软件、按loose版本方案来更新下一行的版本值。注释中的depName必须与 endoflife.date 上登记的软件名称一致。2. 在renovate.json中注册自定义 Manager接下来在renovate.json中配置一个customType: regex的自定义 Manager让 Renovate 去扫描并解析所有.tfvars文件{ customManagers: [ { customType: regex, description: Update Kubernetes version for Amazon EKS in tfvars files, managerFilePatterns: [/.\\.tfvars$/], matchStrings: [ #\\s*renovate:\\s*datasource(?datasource.*?) depName(?depName.*?)( versioning(?versioning.*?))?\\s.*?_version\\s*\\s*\(?currentValue.*)\ ], versioningTemplate: {{#if versioning}}{{{versioning}}}{{/if}} } ], packageRules: [ { matchDatasources: [endoflife-date], matchPackageNames: [amazon-eks], extractVersion: ^(?version.*)-eks.$ } ] }这份配置各部分的职责如下managerFilePatterns限定只处理仓库中匹配/.\.tfvars$/的文件。matchStrings一个正则表达式负责从注释行与赋值行中捕获四个命名组datasource、depName、versioning、currentValue。其中versioning组是可选的( ... )?体现注释里可以不写versioning的容错设计。versioningTemplate使用 Handlebars 模板语法把注释中捕获到的versioning值动态注入若注释未写versioning则回退到数据源默认的loose。packageRules.extractVersion对amazon-eks的版本号做归一化详见下文。3. 执行效果启用以上配置后Renovate 会解析仓库中所有*.tfvars文件定位以# renovate: datasourceendoflife-date depNamedependency-name versioningversioning注释开头、且变量名以_version结尾的赋值行调用 endoflife.date 数据源查询新版本有新版本时自动将currentValue更新为最新版本并提交 PR。针对amazon-eks的packageRule还会额外做一步清洗通过extractVersion正则^(?version.*)-eks.$把类似1.26-eks-1的完整版本号中-eks-${eks-release-version}后缀剥掉只保留 Kubernetes 主次版本号如1.26从而让升级判断聚焦在 Kubernetes 主版本层面。五、extractVersion 的源码级解释extractVersion是 Renovate 在获取版本列表后、进入版本比较前执行的一层预处理。在 lib/modules/datasource/common.ts 的applyExtractVersion中可以看到它的实现const extractVersionRegEx regEx(extractVersion); releaseResult.releases filterMap(releaseResult.releases, (release) { const version extractVersionRegEx.exec(release.version)?.groups?.version; if (!version) { return null; // 无法匹配的版本会被剔除 } release.versionOrig release.version; // 原始版本号被保留到 versionOrig release.version version; return release; });也就是说extractVersion通过具名捕获组(?version...)从 API 返回的版本号中提取出真正参与比较的版本原版本号保存在versionOrig中不会丢失。这一处理发生在 lib/modules/datasource/index.ts 的applyDatasourceFilters调用链中先applyExtractVersion再做过滤、排序去重与约束筛选因此如果某个版本的原始字符串无法被extractVersion匹配它会被直接过滤掉——这提醒我们在编写该正则时要覆盖数据源可能返回的所有版本形态。六、测试用例验证数据解析与异常处理的可靠保证仓库为该数据源提供了完整的单元测试lib/modules/datasource/endoflife-date/index.spec.ts可以作为理解其行为最直观的参考真实数据处理使用eks.json夹具lib/modules/datasource/endoflife-date/fixtures/eks.json模拟 API 响应断言amazon-eks返回 9 个版本其中1.18到1.21等已过 EOL 的版本isDeprecated: true1.22及之后的版本为false且每个版本都带上了releaseTimestamp。布尔型废弃标记使用apache-cassandra.json夹具验证discontinued: true字段布尔型会被正确识别为已废弃。日期型废弃标记使用fairphone.json夹具验证eol为日期字符串时测试中把系统时间固定为2023-06-03通过 luxon 的Settings.now注入早于该时间的eol日期被判定为废弃。边界与异常registryUrl为空时返回nullAPI 返回 404 时返回null返回空数组时返回null返回 5xx 时抛出EXTERNAL_HOST_ERROR。这些测试同时覆盖了 schema 解析、废弃判断、错误处理三个维度说明该数据源在数据不完美缺字段、废弃字段类型不一的情况下也能稳定工作。七、使用建议与注意事项先确认 package 名称depName必须是 endoflife.date 已登记的软件名建议通过其 API 文档中的 All packages 端点核对避免因名称不符导致 404404 时数据源返回nullRenovate 会静默跳过该依赖。版本方案按需收紧默认loose能覆盖大多数情况但如果你的软件版本符合 SemVer 规范优先显式指定versioningsemver以获得更精确的升级判断。extractVersion要写全正则需覆盖该软件 API 可能返回的所有版本形态否则无法匹配的版本会被过滤可能导致漏更新。该数据源适合的软件EKS、Kubernetes 发行版、操作系统版本、语言运行时等没有传统包仓库、但有明确版本与支持周期的软件。它不适用于已有专门 datasource 的生态如 npm 包应使用 npm 数据源。八、相关文件索引数据源实现lib/modules/datasource/endoflife-date/index.ts常量定义lib/modules/datasource/endoflife-date/common.ts响应 Schemalib/modules/datasource/endoflife-date/schema.ts单元测试lib/modules/datasource/endoflife-date/index.spec.ts测试夹具lib/modules/datasource/endoflife-date/fixtures/eks.json、apache-cassandra.json、fairphone.json数据源基类lib/modules/datasource/datasource.ts版本获取与过滤管线lib/modules/datasource/index.ts、lib/modules/datasource/common.ts【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考