Renovate 的 Debian 版本方案：按发行版版本号与代号自动升级 Debian 容器镜像
Renovate 的 Debian 版本方案按发行版版本号与代号自动升级 Debian 容器镜像【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本篇围绕 Renovate 的debian版本解析模块lib/modules/versioning/debian/readme.md展开讲清楚这套方案支持哪些 Debian 容器镜像标签形态、哪些标签形态会被判为不合规并深入源码说明版本校验、stable/oldstable滚动别名解析、带日期后缀标签比较以及“保持用户书写风格”的升级值生成逻辑。读完你可以理解为什么FROM debian:bullseye能被 Renovate 正确升级而11-slim、11.4这类标签却不在该方案的支持范围内。1. 方案定位与适用范围官方文档对 Debian 版本方案versioning scheme的定义非常简洁Debian versioning is used for Debian container images that are referenced by their major release version or a codename.Debian 版本方案用于按主要发行版版本号或代号引用的 Debian 容器镜像。即该方案适用的标签是两种形态数字发行版版本号如11对应 Bullseye、12对应 Bookworm发行代号codename如bullseye、bookworm以及 Debian 的滚动别名stable、oldstable、oldoldstable。文档同时明确了当前实现不合规的标签形态包括11-slim、bullseye-backports这类带变体后缀的标签11.4或11.4-slim这类带点号小版本号的标签。这一点在测试用例中得到印证lib/modules/versioning/debian/index.spec.ts 中isValid(10-slim)期望为falseisVersion(2020.04)期望为falseisVersion(14)数据文件中不存在的版本期望为false。也就是说Renovate 判断一个字符串是否为合法 Debian 版本时会先把它归一化到发行版元数据里查表查不到即视为非法而不是简单按 semver 解析。2. 模块在 Renovate 版本体系中的位置debian是 Renovate 内置版本方案之一与ubuntu、semver、npm等并列注册在全局版本 API 映射表中lib/modules/versioning/api.tsimport * as debian from ./debian/index.ts; // ... api.set(debian.id, debian.api);模块入口在 lib/modules/versioning/debian/index.ts核心元信息为export const id debian; export const displayName Debian; export const supportsRanges true; export const supportedRangeStrategies: RangeStrategy[] [replace];两个关键属性supportsRanges true允许把某个标签当作“范围”去匹配一组版本例如getSatisfyingVersion但supportedRangeStrategies只有replace命中范围后采取“整体替换”策略即直接把当前值替换为新版本而不是像 npm 那样改写区间表达式。实现类DebianVersioningApi继承自通用基类 lib/modules/versioning/generic.ts 中的GenericVersioningApi自身只需重写_parse与若干判断/比较方法isCompatible、getSatisfyingVersion、minSatisfyingVersion、sortVersions等行为由基类基于_parse派生。值得注意的架构细节是debian与ubuntu版本方案共享同一套发行版元数据基础设施lib/modules/versioning/distro.ts 与数据文件ubuntu方案的说明见 lib/modules/versioning/ubuntu/readme.md。这也解释了为什么两套方案的代码结构几乎对称。3. 数据基础debian-distro-info.json整个方案的“事实来源”是发行版元数据文件 data/debian-distro-info.json结构形如{ v1.1: { codename: Buzz, series: buzz, created: 1993-08-16, release: 1996-06-17, eol: 1997-06-05 }, v2: { codename: Hamm, series: hamm, ...: ... } }每个条目包含版本号的codename展示名首字母大写、series代号全小写如bullseye、created、release、eol等日期字段eol与eol_lts的取舍逻辑见 lib/modules/versioning/distro.ts 中isEolLts的注释“debian: only Stable has no eol_lts, old and oldold has both”。两个工程化细节加载时去掉v前缀DistroInfo构造器用正则v(?version[\d.])\b把键v11归一为11后再解析因此代码里统一用11这样的裸版本号查询。数据定期再生该文件由 tools/static-data/generate-distro-info.mjs 从 Debian 官方的 distro-info-data CSV 抓取转换而来ubuntu.csv/debian.csv两个来源CSV 中的2.0会被规范化为2并加上v前缀。换句话说Renovate 的 Debian 方案能识别哪些版本、哪些代号完全由这份静态快照决定——这也是为什么测试用例里forky、Trixie尚未出现在数据文件中或大小写不符会被判为false。DistroInfo类对外提供了代号/版本号双向查询getVersionByCodename/getCodenameByVersion、状态判断isReleased/isCreated/isEolLts均以当前 UTC 时间与release/created/eol字段比较并预留 1 天缓冲delay 1以及“取第 N 新发行版”的getNLatest(n)n0对应 stable、n1对应 oldstable、n2对应 oldoldstable。4. 版本解析与合法性判断DebianVersioningApi的私有_parse是整个方案的核心lib/modules/versioning/debian/index.tsprotected override _parse(version: string): GenericVersion | null { let ver: string; if (isDatedCodeName(version, this._distroInfo)) { const codename getDatedContainerImageCodename(version)!; ver this._distroInfo.getVersionByCodename(codename); } else { ver this._rollingReleases.getVersionByLts(version); ver this._distroInfo.getVersionByCodename(ver); } if (!this._distroInfo.exists(ver)) { return null; } return { release: ver.split(.).map(Number) }; }解析链路可归纳为四步若输入是带日期后缀的代号标签见下文先取出代号否则先用RollingReleasesData把stable/oldstable/oldoldstable解析为具体版本号再用DistroInfo把代号解析为数字版本号归一化后的版本号必须存在于元数据文件中否则返回null即非法。解析成功后返回{ release: [major, minor, ...] }于是getMajor/getMinor/getPatch都只是取release数组下标。测试中getMajor(oldoldstable) 10、getMajor(stable) 12以固定测试时间 2023-07-10 计算正体现了滚动别名会被解析成当时对应的具体版本。4.1 带日期后缀的代号标签lib/modules/versioning/debian/common.ts 定义了专用正则const datedRegex regEx( /^(?codename\w)-(?date\d{8})(?suffix\.\d{1,2})?$/, );即codename-YYYYMMDD可选.1~.99两位以内修订后缀。配套函数isDatedCodeName(input, distroInfo)正则匹配且前缀确为已知代号getDatedContainerImageCodename/getDatedContainerImageVersion/getDatedContainerImageSuffix分别提取代号、日期数字如20230816、修订后缀。从源码与测试common.spec.ts、index.spec.ts看当前实现对bullseye-20220101、bookworm-20230816.1这类标签已完整支持isValid、isStable、equals、isGreaterThan均能正确处理而invalid-20230816未知代号、bookworm-2023081日期不足 8 位、bookworm-20230816.123后缀超过 2 位均判为非法。需要说明的是readme 中“bullseye-20220822不合规”的表述出自早期实现口径与当前源码行为存在偏差撰写本文时以源码及测试为准可以推断 README 未随带日期标签特性同步更新。文档中列出的11-slim、11.4等形态在当前代码中依然判为不合规与测试一致。5. 滚动别名stable / oldstable / oldoldstableDebian 官方允许用stable等滚动别名指代“当前最新/次新发行版”。Renovate 用RollingReleasesData类lib/modules/versioning/debian/common.ts实现动态映射private build(): void { const now DateTime.now().toUTC(); if (now this.timestamp.plus(refreshInterval)) { return; } // refreshInterval { days: 1 } for (let i 0; i 3; i) { const di this.distroInfo.getNLatest(i); let prefix ; for (let j 0; j i; j) prefix old; di.series ${prefix}stable; this.ltsToVer.set(di.series, di); this.verToLts.set(di.version, di); } }要点只取最近 3 个已发布版本分别命名为stable、oldstable、oldoldstable前缀按old叠加映射基于DistroInfo.getNLatest(n)而isReleased与当前日期比较因此别名指向的版本会随时间推移自动前移为避免高频重建build带 1 天刷新窗口refreshInterval { days: 1 }重建时打印RollingReleasesData - data written调试日志。测试 index.spec.ts 中用vi.setSystemTime验证了两点1 天窗口内不会重复刷新把系统时间跳到 2019 年与未来 3 年后isStable(buster)的结果会从true变为false因为 Buster 在新时间线下已越过 EOL。isStable的判定规则index.ts是版本已发布isReleased且尚未越过 EOL-LTS!isEolLts。对带日期后缀的标签则先把日期标签还原为代号对应的版本再做同样判断。测试中isStable(buster)在 2023-07-10 为true而isStable(trixie)未发布为false。6. getNewValue升级后保持用户的书写风格Renovate 生成升级后的新值时getNewValue的核心原则是保留当前值的形式当前写的是代号就返回代号写的是数字就返回数字写的是滚动别名就返回别名。源码逻辑可拆成四条分支index.ts当前值是滚动别名stable等→ 返回新版本号对应的滚动别名getLtsByVersion当前值是代号 → 新版本号换算回代号返回新版本是滚动别名、当前是数字 → 返回该别名当前指向的数字版本schedule(newVersion).version新版本是带日期后缀的代号标签而当前是数字 → 仅取其基础数字版本返回不做格式切换_getBaseVersion。测试用例集中体现了这些行为固定时间 2023-07-10当前值新版本生成结果说明stretch11bullseye数字→代号stretchstablebookworm别名→代号2023-07 时 stable 指向 1291111数字保持数字9stable12别名→数字oldoldstable12stable别名保持别名12 当时是 stableoldstable33目标不在最近三代内别名映射不成立原样返回12bookworm-2023081612数字当前值遇日期标签取基础版本bullseyebookworm-20230816bookworm代号当前值遇日期标签取代号第 6、7 行揭示了两个实用细节滚动别名只覆盖最近三代发行版映射不到时按原值透传日期后缀标签不会把用户的数字/代号写法“污染”成日期标签形式。7. 比较、相等与范围匹配isGreaterThan在带日期标签参与时采用多级比较index.ts先比主版本再比次版本再比日期数字20230816vs20230817再比修订后缀.1晚于无后缀测试断言bookworm-20230816.1 bookworm-20230816最后比 patch。由此得到测试中验证的结论例如isGreaterThan(bookworm-20230817, bookworm-20230816) trueisGreaterThan(bullseye-20220101, 11) true同一大版本下日期快照标签被视为晚于纯版本号sortVersions(12, oldoldstable) 2、sortVersions(10, stable) -2滚动别名参与排序时同样先归一化为具体版本。equals对日期标签则逐段比较“日期 后缀 基础版本”例如bookworm-20230816与bookworm-20230817不相等而与自身相等。范围侧能力由基类派生并在测试中验证getSatisfyingVersion([8,9,10,11], 11) 11对stable这类范围会先在列表中找同代版本如[jessie,stretch,oldstable,bullseye]匹配bullseye时返回oldstable因为 bullseye 即当时的 oldstableminSatisfyingVersion返回范围内最低版本matches(11, 11) true而matches(11, 11.0) false、matches(10, 10-slim) false——再次说明带-slim/点号变体的标签不参与匹配。8. 使用与边界结合上述实现使用debian版本方案时的实际边界是可用场景Dockerfile 或容器编排文件中以debian:major、debian:codename、debian:rolling-alias以及codename-YYYYMMDD[.N]形式引用 Debian 基础镜像的依赖升级。用户可在 Renovate 配置中通过versioning选项指定debian该值即 api.ts 中注册的id。明确不支持11-slim、11.4、bullseye-backports等带变体后缀或非发行版语义的标签。这类标签会走其他版本方案如ubuntu方案或docker方案的宽松解析处理Renovate 不会用本方案对它们做版本判断。时间敏感性stable等别名的指向、isStable的结论都依赖运行时刻与数据文件中的release/eol日期数据文件本身由 tools/static-data/generate-distro-info.mjs 周期性再生。新代号如测试中的forky在数据文件中出现之前会被判为非法。范围策略单一supportedRangeStrategies仅replace升级即整体替换标签值不存在区间改写。9. 可核对的关键文件lib/modules/versioning/debian/readme.md方案适用标签形态的官方说明lib/modules/versioning/debian/index.tsDebianVersioningApi的解析、稳定判断、比较与getNewValuelib/modules/versioning/debian/common.ts日期标签正则与RollingReleasesData滚动别名映射lib/modules/versioning/debian/index.spec.ts、common.spec.ts全部判定行为的测试矩阵lib/modules/versioning/distro.ts与ubuntu方案共享的发行版元数据抽象data/debian-distro-info.json版本/代号/日期事实数据tools/static-data/generate-distro-info.mjs静态数据再生脚本lib/modules/versioning/api.tsdebian方案的全局注册点。综上Renovate 的 Debian 版本方案是一个“以静态发行版元数据为事实来源、以滚动别名为动态补充、以用户书写风格为输出约束”的定制版本体系它不追求通用 semver 表达力而是精确对齐 Debian 容器镜像标签的真实用法并通过日期标签的多级比较与getNewValue的风格保持让bullseye → bookworm、11 → 12、oldstable → stable这类升级在拉取 PR 时以用户最熟悉的形式呈现。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考