Renovate terra-version Manager 深度解析.terraform-version文件的依赖自动升级机制【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 通过名为terraform-version的 manager 专门维护项目根目录或任意目录中的.terraform-version文件这类文件通常被 Terraform 本地版本管理工具用来声明项目应使用的 Terraform 版本。本篇基于当前仓库源码完整讲解该 manager 的文件匹配规则、依赖提取逻辑、版本来源GitHub Releases 数据源、HashiCorp 版本语法处理以及它与通用terraformmanager 的分工边界帮助你在renovate.json中正确配置并排查该 manager 的行为。一、Manager 定位它管理什么该模块位于 lib/modules/manager/terraform-version原始文档 readme.md 只有一句话概括This will maintain.terraform-versionfiles. Available versions will be determined from the official Terraform downloads page.维护.terraform-version文件可用版本来自官方发布渠道。而当前仓库的源码给出了更精确的实现事实manager 标识terraform-version在 lib/modules/manager/api.ts 第 229 行通过api.set(terraform-version, terraformVersion)注册因此可以在配置中用managers: [terraform-version]或enabledManagers显式开关它。显示名称index.ts 第 7 行导出displayName .terraform-version在 Renovate 生成的 PR、Dashboard 中该 manager 就以文件名本身呈现。所属分类categories: [terraform]与 Terraform 生态相关的 manager 归入同一分类。二、文件匹配规则managerFilePatterns在 index.ts 的defaultConfig第 10–14 行中定义了核心默认配置export const defaultConfig { managerFilePatterns: [/(^|/)\\.terraform-version$/], versioning: hashicorpVersioning.id, extractVersion: ^v(?version.*)$, };逐项解读配置项取值作用managerFilePatterns/(^|/)\\.terraform-version$/正则要求文件名恰好为.terraform-version前面是路径起始或/分隔符即仓库任意层级的该文件都会被扫描而不会误匹配xxx.terraform-version之类后缀versioninghashicorp指定使用 HashiCorp 版本语法做版本比较与范围解析见第五节extractVersion^v(?version.*)$从数据源返回的版本号中用命名捕获组version剥离前导v前缀例如 tagv1.10.2会被规范化为1.10.2这意味着你只需在仓库中放一个.terraform-version文件例如1.5.7Renovate 运行后就会识别出该文件并为其创建升级 PR。三、依赖提取逻辑整个文件内容即 currentValue提取实现在 extract.ts全部核心逻辑只有 13 行export function extractPackageFile(content: string): PackageFileContent { logger.trace(terraform-version.extractPackageFile()); const dep: PackageDependency { depName: hashicorp/terraform, currentValue: content.trim(), datasource: GithubReleasesDatasource.id, }; return { deps: [dep] }; }关键行为有三点depName 硬编码为hashicorp/terraform。因为该文件本身不携带包名信息manager 直接假定文件内容就是 Terraform 的版本声明仓库名固定为hashicorp/terraform。currentValue就是文件内容去除首尾空白后的结果content.trim()。所以文件里写1.5.7、 1.3、~ 1.4.0等都可以被提取extract.spec.ts 中的测试用例直接印证了这一点输入12.0.0\n得到currentValue: 12.0.0输入latest也会原样提取为currentValue: latest测试名为 skips non ranges即提取阶段不做校验非法值会在后续版本比较阶段被自然忽略。数据源指定为github-releases。四、版本来源github-releases 数据源需要指出一个文档与实现的差异原始 readme 提到official Terraform downloads page但从当前源码结构看版本清单实际来自 GitHub 上hashicorp/terraform仓库的 Releases。supportedDatasources在 index.ts 第 16 行声明为[GithubReleasesDatasource.id]该数据源实现于 lib/modules/datasource/github-releases/index.ts默认注册表地址为https://github.comdefaultRegistryUrls第 20 行因此packageName hashicorp/terraform会被解析为该仓库的 release 列表getReleases()通过 GraphQL 的queryReleases拉取 release 列表第 74 行把每条 release 映射为包含version、gitRef、releaseTimestamp、isStable的Release对象结合第三节提到的extractVersion: ^v(?version.*)$Terraform 仓库中形如v1.9.8的 tag 在入库前会被去掉v前缀保证与.terraform-version中不带前缀的写法一致该数据源还支持 digest 解析getDigest通过findCommitOfTag取 tag 对应的 commit SHA但对本 manager 的常规版本升级场景无直接影响。从源码结构看若你自托管需要访问内网 GitHub Enterprise可通过hostRules/数据源registryUrl覆盖默认的https://github.com这是github-releases数据源通用能力而非本 manager 专属配置。五、版本比较与范围策略hashicorp versioningdefaultConfig中的versioning: hashicorp指向 lib/modules/versioning/hashicorp/index.ts这是理解本 manager 如何处理范围写法的关键支持范围supportsRanges true第 13 行即.terraform-version中写 1.3这类约束也能被识别与升级范围策略supportedRangeStrategies: [bump, widen, replace]第 14–18 行对应 Renovate 全局rangeStrategy的三种取值决定范围如何随新版本移动底层实现是转换为 npm 语法再比较API 展开自 npm versioning...npm并在其上覆写matches、getSatisfyingVersion、minSatisfyingVersion、getNewValue等方法。转换函数位于 lib/modules/versioning/hashicorp/convertor.tshashicorp2npm()第 20–68 行把 HashiCorp 约束逐条翻译成 npm 范围例如~ 1.4→^1.4、~ 1→1、~ 1.4.0→~1.4.0多条以逗号分隔的约束会被空格连接npm2hashicorp()第 75–131 行做反向转换把 npm 的^/~结果翻译回~语法保证 PR 写回文件的是 HashiCorp 风格明确的限制!语法在hashicorp2npm中会直接抛错第 39–45 行源码注释说明npm 没有直接等价写法所以.terraform-version中不要使用!约束否则该值无法参与匹配计算getNewValue还保留了一个细节若原值以v开头如v1.5.7生成的新值也会补回v前缀第 93–95 行。因此当.terraform-version内容为~ 1.5而 upstream 发布1.6.0时Renovate 会依据widen/bump等策略计算出新的范围字符串并发起 PR而不是简单覆盖为精确版本。六、配置示例与常见用法基于以上源码事实一个最小可用的启用方式如下renovate.json片段均为仓库配置项的真实语义{ managers: { terraform-version: { enabled: true } }, packageRules: [ { matchManagers: [terraform-version], rangeStrategy: widen } ] }说明该 manager 属于默认启用的 manager 之一通过api.set注册进全局 manager 集合显式配置仅在你需要调整rangeStrategy、ignoreUnstable等通用选项时有必要因为文件模式是任意目录下的.terraform-version多模块仓库中每个目录各自的文件都会被独立维护若你希望 Terraform 版本升级更保守例如只在 minor 内升级可以直接在packageRules中针对该 manager 限制matchUpdateTypes这些是 Renovate 全局通用机制本 manager 无需额外配置即可享受。七、与 terraform manager 的分工仓库中还存在一个通用的 terraform manager二者职责不同配置时容易混淆terraform-version本文主角只认.terraform-version这种独立纯文本文件depName 恒为hashicorp/terraformterraformmanager解析.tf/.hcl等 HCL 文件中的terraform { required_version ... }块其提取器位于 lib/modules/manager/terraform/extractors/terraform-block/terraform-version.ts处理的是 Terraform 模块自身声明的版本约束。如果你的仓库同时存在这两种声明两个 manager 会各自维护各自的文件互不干扰。八、局限与注意事项结合 extract.spec.ts 与源码使用本 manager 时应注意内容必须是单个版本或单个/一组 HashiCorp 约束。提取器不做任何解析校验trim()之后原样作为currentValue写入latest之类的非版本值虽然能通过提取但不会匹配到任何 release也就不会产生升级 PR测试用例 skips non ranges 即覆盖了这一输入。!约束不受 hashicorp versioning 支持见第五节 convertor 实现应避免在.terraform-version中使用。预发布号兼容性有限convertor 源码注释明确说明 HashiCorp 的 prerelease 语法定义不严格非 semver 兼容的 prerelease 写法不会做转换尝试可能产生匹配问题。版本清单依赖 GitHub Releases数据源为github-releases其可用性取决于对hashicorp/terraform仓库 release API 的访问可被 Renovate 的 GitHub 缓存与 rate limit 策略影响tag 的v前缀由 manager 级extractVersion统一剥离配置时无需手工处理。小结terraform-version是一个小而专的 manager文件模式单一.terraform-version、提取逻辑直白文件内容即 currentValue、依赖hashicorp/terraform的 GitHub Releases 与hashicorp版本语法完成比较与升级。理解 index.ts 的三行defaultConfig、extract.ts 的提取逻辑以及 hashicorp versioning 的范围转换规则就足以掌握该模块的全部行为边界并在仓库中放心地用它保持 Terraform 版本的持续更新。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Renovate terra-version Manager 深度解析：`.terraform-version` 文件的依赖自动升级机制
Renovate terra-version Manager 深度解析.terraform-version文件的依赖自动升级机制【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovateRenovate 通过名为terraform-version的 manager 专门维护项目根目录或任意目录中的.terraform-version文件这类文件通常被 Terraform 本地版本管理工具用来声明项目应使用的 Terraform 版本。本篇基于当前仓库源码完整讲解该 manager 的文件匹配规则、依赖提取逻辑、版本来源GitHub Releases 数据源、HashiCorp 版本语法处理以及它与通用terraformmanager 的分工边界帮助你在renovate.json中正确配置并排查该 manager 的行为。一、Manager 定位它管理什么该模块位于 lib/modules/manager/terraform-version原始文档 readme.md 只有一句话概括This will maintain.terraform-versionfiles. Available versions will be determined from the official Terraform downloads page.维护.terraform-version文件可用版本来自官方发布渠道。而当前仓库的源码给出了更精确的实现事实manager 标识terraform-version在 lib/modules/manager/api.ts 第 229 行通过api.set(terraform-version, terraformVersion)注册因此可以在配置中用managers: [terraform-version]或enabledManagers显式开关它。显示名称index.ts 第 7 行导出displayName .terraform-version在 Renovate 生成的 PR、Dashboard 中该 manager 就以文件名本身呈现。所属分类categories: [terraform]与 Terraform 生态相关的 manager 归入同一分类。二、文件匹配规则managerFilePatterns在 index.ts 的defaultConfig第 10–14 行中定义了核心默认配置export const defaultConfig { managerFilePatterns: [/(^|/)\\.terraform-version$/], versioning: hashicorpVersioning.id, extractVersion: ^v(?version.*)$, };逐项解读配置项取值作用managerFilePatterns/(^|/)\\.terraform-version$/正则要求文件名恰好为.terraform-version前面是路径起始或/分隔符即仓库任意层级的该文件都会被扫描而不会误匹配xxx.terraform-version之类后缀versioninghashicorp指定使用 HashiCorp 版本语法做版本比较与范围解析见第五节extractVersion^v(?version.*)$从数据源返回的版本号中用命名捕获组version剥离前导v前缀例如 tagv1.10.2会被规范化为1.10.2这意味着你只需在仓库中放一个.terraform-version文件例如1.5.7Renovate 运行后就会识别出该文件并为其创建升级 PR。三、依赖提取逻辑整个文件内容即 currentValue提取实现在 extract.ts全部核心逻辑只有 13 行export function extractPackageFile(content: string): PackageFileContent { logger.trace(terraform-version.extractPackageFile()); const dep: PackageDependency { depName: hashicorp/terraform, currentValue: content.trim(), datasource: GithubReleasesDatasource.id, }; return { deps: [dep] }; }关键行为有三点depName 硬编码为hashicorp/terraform。因为该文件本身不携带包名信息manager 直接假定文件内容就是 Terraform 的版本声明仓库名固定为hashicorp/terraform。currentValue就是文件内容去除首尾空白后的结果content.trim()。所以文件里写1.5.7、 1.3、~ 1.4.0等都可以被提取extract.spec.ts 中的测试用例直接印证了这一点输入12.0.0\n得到currentValue: 12.0.0输入latest也会原样提取为currentValue: latest测试名为 skips non ranges即提取阶段不做校验非法值会在后续版本比较阶段被自然忽略。数据源指定为github-releases。四、版本来源github-releases 数据源需要指出一个文档与实现的差异原始 readme 提到official Terraform downloads page但从当前源码结构看版本清单实际来自 GitHub 上hashicorp/terraform仓库的 Releases。supportedDatasources在 index.ts 第 16 行声明为[GithubReleasesDatasource.id]该数据源实现于 lib/modules/datasource/github-releases/index.ts默认注册表地址为https://github.comdefaultRegistryUrls第 20 行因此packageName hashicorp/terraform会被解析为该仓库的 release 列表getReleases()通过 GraphQL 的queryReleases拉取 release 列表第 74 行把每条 release 映射为包含version、gitRef、releaseTimestamp、isStable的Release对象结合第三节提到的extractVersion: ^v(?version.*)$Terraform 仓库中形如v1.9.8的 tag 在入库前会被去掉v前缀保证与.terraform-version中不带前缀的写法一致该数据源还支持 digest 解析getDigest通过findCommitOfTag取 tag 对应的 commit SHA但对本 manager 的常规版本升级场景无直接影响。从源码结构看若你自托管需要访问内网 GitHub Enterprise可通过hostRules/数据源registryUrl覆盖默认的https://github.com这是github-releases数据源通用能力而非本 manager 专属配置。五、版本比较与范围策略hashicorp versioningdefaultConfig中的versioning: hashicorp指向 lib/modules/versioning/hashicorp/index.ts这是理解本 manager 如何处理范围写法的关键支持范围supportsRanges true第 13 行即.terraform-version中写 1.3这类约束也能被识别与升级范围策略supportedRangeStrategies: [bump, widen, replace]第 14–18 行对应 Renovate 全局rangeStrategy的三种取值决定范围如何随新版本移动底层实现是转换为 npm 语法再比较API 展开自 npm versioning...npm并在其上覆写matches、getSatisfyingVersion、minSatisfyingVersion、getNewValue等方法。转换函数位于 lib/modules/versioning/hashicorp/convertor.tshashicorp2npm()第 20–68 行把 HashiCorp 约束逐条翻译成 npm 范围例如~ 1.4→^1.4、~ 1→1、~ 1.4.0→~1.4.0多条以逗号分隔的约束会被空格连接npm2hashicorp()第 75–131 行做反向转换把 npm 的^/~结果翻译回~语法保证 PR 写回文件的是 HashiCorp 风格明确的限制!语法在hashicorp2npm中会直接抛错第 39–45 行源码注释说明npm 没有直接等价写法所以.terraform-version中不要使用!约束否则该值无法参与匹配计算getNewValue还保留了一个细节若原值以v开头如v1.5.7生成的新值也会补回v前缀第 93–95 行。因此当.terraform-version内容为~ 1.5而 upstream 发布1.6.0时Renovate 会依据widen/bump等策略计算出新的范围字符串并发起 PR而不是简单覆盖为精确版本。六、配置示例与常见用法基于以上源码事实一个最小可用的启用方式如下renovate.json片段均为仓库配置项的真实语义{ managers: { terraform-version: { enabled: true } }, packageRules: [ { matchManagers: [terraform-version], rangeStrategy: widen } ] }说明该 manager 属于默认启用的 manager 之一通过api.set注册进全局 manager 集合显式配置仅在你需要调整rangeStrategy、ignoreUnstable等通用选项时有必要因为文件模式是任意目录下的.terraform-version多模块仓库中每个目录各自的文件都会被独立维护若你希望 Terraform 版本升级更保守例如只在 minor 内升级可以直接在packageRules中针对该 manager 限制matchUpdateTypes这些是 Renovate 全局通用机制本 manager 无需额外配置即可享受。七、与 terraform manager 的分工仓库中还存在一个通用的 terraform manager二者职责不同配置时容易混淆terraform-version本文主角只认.terraform-version这种独立纯文本文件depName 恒为hashicorp/terraformterraformmanager解析.tf/.hcl等 HCL 文件中的terraform { required_version ... }块其提取器位于 lib/modules/manager/terraform/extractors/terraform-block/terraform-version.ts处理的是 Terraform 模块自身声明的版本约束。如果你的仓库同时存在这两种声明两个 manager 会各自维护各自的文件互不干扰。八、局限与注意事项结合 extract.spec.ts 与源码使用本 manager 时应注意内容必须是单个版本或单个/一组 HashiCorp 约束。提取器不做任何解析校验trim()之后原样作为currentValue写入latest之类的非版本值虽然能通过提取但不会匹配到任何 release也就不会产生升级 PR测试用例 skips non ranges 即覆盖了这一输入。!约束不受 hashicorp versioning 支持见第五节 convertor 实现应避免在.terraform-version中使用。预发布号兼容性有限convertor 源码注释明确说明 HashiCorp 的 prerelease 语法定义不严格非 semver 兼容的 prerelease 写法不会做转换尝试可能产生匹配问题。版本清单依赖 GitHub Releases数据源为github-releases其可用性取决于对hashicorp/terraform仓库 release API 的访问可被 Renovate 的 GitHub 缓存与 rate limit 策略影响tag 的v前缀由 manager 级extractVersion统一剥离配置时无需手工处理。小结terraform-version是一个小而专的 manager文件模式单一.terraform-version、提取逻辑直白文件内容即 currentValue、依赖hashicorp/terraform的 GitHub Releases 与hashicorp版本语法完成比较与升级。理解 index.ts 的三行defaultConfig、extract.ts 的提取逻辑以及 hashicorp versioning 的范围转换规则就足以掌握该模块的全部行为边界并在仓库中放心地用它保持 Terraform 版本的持续更新。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
