Renovate 的 bazel-module Manager 完整指南用 bzlmod 统一管理 Bazel、Maven、Docker 与 Rust 依赖【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate本篇指南聚焦 Renovate CLI 中的bazel-modulemanager讲解它如何扫描启用 Bazel modulebzlmod。一、Manager 定位面向 bzlmod 工作区的统一依赖管理器bazel-modulemanager 的核心目标是更新启用了Bazel modulebzlmod的工作区。Bazel 7 起 bzlmod 成为默认的外部依赖管理模式依赖声明集中在仓库根目录的MODULE.bazel文件中版本解析结果固化在MODULE.bazel.lock锁文件里。从该 manager 的入口实现lib/modules/manager/bazel-module/index.ts可以看出它的设计边界匹配文件managerFilePatterns: [/(^|/|\\.)MODULE\\.bazel$/]即凡是文件名匹配MODULE.bazel的文件都会被提取依赖因此子目录中嵌套的模块文件同样受支持。支持的数据源BazelDatasourceBazel 官方模块注册表 BCR、MavenDatasourceMaven Central 等、DockerDatasourceOCI 镜像、CrateDatasourcecrates.io与GithubTagsDatasourceGit 仓库标签。锁文件声明lockFileNames [MODULE.bazel.lock]并开启supportsLockFileMaintenance锁文件维护模式。分类归类为bazel类别文档地址指向 bazel.build/external/module。依赖提取的总体流程位于 lib/modules/manager/bazel-module/extract.ts先用 Starlark 解析器解析MODULE.bazel内容得到结构化片段再分别调用 Maven、OCI、crate、git_repository 与bazel_dep等规则转换器把每个片段映射为 Renovate 标准的PackageDependency对象只有解析出至少一个依赖时才返回结果解析失败则记录 debug 日志并返回null。二、识别出的依赖类型depType 全景lib/modules/manager/bazel-module/dep-types.ts 集中声明了该 manager 能识别的 11 种依赖类型这既是文档化能力清单也是每个依赖在 PR 中被标注的类别depType含义bazel_dep通过bazel_dep声明的直接 Bazel 模块依赖git_override通过git_override对模块依赖做的 Git 覆盖archive_override通过archive_override做的归档覆盖local_path_override通过local_path_override做的本地路径覆盖single_version_override通过single_version_override做的版本/注册表覆盖git_repository模块扩展中以git_repository引入的 Git 仓库依赖new_git_repository模块扩展中以new_git_repository带自定义 BUILD 文件引入的 Git 仓库依赖oci_pull通过oci.pull扩展标签拉取的 OCI 容器镜像maven_install通过maven模块扩展安装的 Maven 构件crate_spec通过crate.spec扩展标签声明的 Rust crate 依赖rules_img_pull模块扩展中通过rules_img仓库规则拉取的容器镜像其中bazel_dep、git_override、single_version_override、archive_override、local_path_override以及模块扩展里的git_repository/new_git_repository由 lib/modules/manager/bazel-module/rules.ts 处理其余由对应的专用解析器处理。三、bazel_dep与模块覆盖override语义MODULE.bazel中最基础的依赖声明是bazel_dep形如bazel_dep(name rules_foo, version 1.2.3)结合 lib/modules/manager/bazel-module/rules.ts 的实现解析与更新规则如下bazel_dep以BazelDatasource查 BCRdepName取namecurrentValue取version若省略version会标记skipReason: unspecified-version即该依赖不会被更新。git_override把remote解析为 GitHub 仓库仅支持 GitHub 远程地址以GithubTagsDatasource跟踪 tag同时把commit记录为currentDigest非 GitHub 远程会标记unsupported-datasource。single_version_override若指定了version视为“已钉死”的覆盖is-pinned并把该版本合并进对应的bazel_dep若指定了registry则把该注册表 URL 合并进bazel_dep的registryUrls。archive_override/local_path_override属于本地或文件依赖Renovate 不做更新分别标记file-dependency/local-dependency跳过原因。从源码结构看rules.ts会把同一模块名的多条声明bazel_dep与各类 override按模块名归组collectByModule再由processModulePkgDeps合并最终以bazel_dep为输出主体把 override 的版本/注册表信息合并进去若一个模块存在多个 override出于语义歧义会忽略全部 override 并记录日志。这意味着你可以放心在MODULE.bazel中同时使用 override 来钉版本或换源Renovate 依然只会产出一条针对该模块的更新。四、Maven 构件maven.install与maven.artifactbazel-module也会处理通过 bzlmod 初始化的 Maven 构件。为降低解析复杂度扩展变量名被限制为以maven开头例如maven use_extension(rules_jvm_external//:extensions.bzl, maven)maven_1 use_extension(rules_jvm_external//:extensions.bzl, maven)install和artifact两种方法都受支持maven.install( artifacts [ org.seleniumhq.selenium:selenium-java:4.4.0, ], ) maven.artifact( artifact javapoet, group com.squareup, neverlink True, version 1.11.1, )对应的解析实现在 lib/modules/manager/bazel-module/parser/maven.tsmaven.installartifacts数组中的每个字符串按:切分为group:artifact:version使用MavenDatasource与 Gradle 版本规则versioning/gradle解析版本repositories参数中的仓库地址会被收集为该依赖的registryUrls。maven.artifact从group、artifact、version字段组装depName其registryUrls会继承同一文件中maven.install声明的仓库列表fillRegistryUrls负责这一合并逻辑并统一以maven_install作为 depType 输出。这意味着无论使用坐标字符串列表还是显式字段形式Renovate 都能识别group:artifact:version三元组并精确替换版本号。五、Docker / OCI 镜像oci.pull与rules_img的pullbazel-module同样更新通过oci_pull拉取的 Docker / OCI 镜像。注意扩展必须命名为ocioci use_extension(rules_oci//oci:extensions.bzl, oci) oci.pull( name nginx_image, digest sha256:287ff321f9e3cde74b600cc26197424404157a72043226cbbf07ee8304a2c720, image index.docker.io/library/nginx, platforms [linux/amd64], tag 1.27.1, )lib/modules/manager/bazel-module/parser/oci.ts 的实现细节扩展名被z.literal(oci)严格限定tag 限定为pullname作为depNameimage作为packageNametag作为currentValuedigest作为currentDigest数据源为DockerDatasource并保留原始rawString作为replaceString这样当tag与digest同时存在时自动替换器可以一次性替换两者这正是oci.pull既有 tag 又有 digest 时能正确更新的关键提取阶段还会通过 dockerfile manager 的getDep逻辑结合registryAliases处理镜像注册表别名。此外它支持通过 rules_img 的pull仓库规则拉取的镜像pull use_repo_rule(rules_img//img:pull.bzl, pull) pull( name ubuntu, digest sha256:1e622c5f9ac0c0144d577702ba5f2cce79fc8e3cf89ec88291739cd4eee3b7b9, registry index.docker.io, repository library/ubuntu, tag 24.04, )这部分由 lib/modules/manager/bazel-module/rules-img.ts 中的transformRulesImgCalls处理将registry、repository、tag、digest组装成与oci.pull同构的 Docker 依赖depType 为rules_img_pull。两套声明方式可以共存于同一MODULE.bazel中。六、Rust cratecrate.spec对于使用 rules_rust crate_universe 初始化的 Rust crate 依赖扩展变量名同样被限制为以crate开头crate use_extension(rules_rust//crate_universe:extension.bzl, crate)crate_1 use_extension(rules_rust//crate_universe:extension.bzl, crate)spec方法受支持可同时处理 crates.io 版本号与 Git 来源crate.spec( package axum, version 0.8.4, ) crate.spec( package tokio, version 1.45.1, features [ full, ], ) crate.spec( package custom_crate, git https://github.com/example/custom_crate.git, tag v1.0.0, )lib/modules/manager/bazel-module/parser/crate.ts 的解析逻辑数据源为CrateDatasourcepackage作为depName有version时以 SemVer 版本作为currentValue并标记nestedVersion供后端判断是否属于嵌套版本声明指定git时通过applyGitSource依据rev/tag/branch生成对应的 Git 数据源GitHub 仓库以 tag 更新指定path本地路径依赖时标记path-dependency跳过既无版本又无 git 来源时标记invalid-dependency-specification。因此版本来自 crates.io 的依赖会按 crates.io 发布版本更新而 Git 来源的依赖则按 Git tag/commit 更新。七、Git 仓库依赖模块扩展中的git_repository与new_git_repository除了模块级声明模块扩展module extension内部常见的git_repository/new_git_repository调用也会被识别见 lib/modules/manager/bazel-module/rules.ts 中的GitRepositoryToPackageDepgit_repository( name some_repo, remote https://github.com/org/some_repo.git, tag v1.2.3, )解析规则仅当remote是 GitHub 地址时才会更新githubPackageName从 URL 提取org/repo数据源为GithubTagsDatasource指定commit时记录为currentDigest指定tag时记录为currentValue非 GitHub 远程地址标记unsupported-datasource并跳过。八、从.bazelrc读取注册表配置bazel-module还支持从仓库的.bazelrc文件中读取--registry选项作为 Bazel 模块依赖的额外注册表 URL。实现位于 lib/modules/manager/bazel-module/bazelrc.ts解析.bazelrc中的import/try-import指令并递归读取被导入的文件带防重复读取保护同时解析command:config --optionvalue形式的命令行选项只采纳没有config限定即通用配置的--registry值并支持%workspace%占位符展开提取阶段extract.ts 的extractBazelPfc把这些 URL 收集到pfc.registryUrls供 Bazel 模块数据源查询版本时使用。这让你可以在.bazelrc中配置私有 BCR 镜像或企业内网注册表Renovate 会自动跟随。九、锁文件支持更新MODULE.bazel.lock当依赖发生变更时bazel-module会同步更新MODULE.bazel.lock锁文件。相关流程在 lib/modules/manager/bazel-module/artifacts.ts 与 lib/modules/manager/bazel-module/lockfile.ts 中实现更新MODULE.bazel内容后检查同目录是否存在MODULE.bazel.lock若仓库中不存在锁文件则跳过锁文件更新步骤。找到锁文件后执行bazel mod deps --lockfile_modeupdate重新生成锁文件。执行完成后对比 Git 状态若锁文件确实发生修改则把新内容作为文件变更附加到 PR 中。启用锁文件更新需要满足以下前提仓库中已存在MODULE.bazel.lock文件Bazelisk 可用使用 containerbase 环境时 Renovate 会自动安装若仓库存在.bazelversion文件Bazelisk 会据此确定要使用的 Bazel 版本。安全白名单是硬性门槛该命令只有在全局配置选项allowedUnsafeExecutions中包含bazelModDeps时才会真正执行。若未包含lockfile.ts 会输出一条Bazel command was requested to run, but bazelModDeps is not permitted in the allowedUnsafeExecutions的告警并直接跳过而不会运行任何命令。启用方式自托管配置参见 docs/usage/self-hosted-configuration.md 中的allowedUnsafeExecutions说明{ allowedUnsafeExecutions: [bazelModDeps], }此外在锁文件维护模式lock file maintenance下Renovate 会先删除既有锁文件再重新生成从而让 Bazel 从零解析依赖图达到“重刷锁文件”的效果若命令执行失败会把错误信息以artifactError形式反馈到 PR 中方便排查。执行时还可通过config.constraints.bazelisk指定 Bazelisk 的版本约束。十、典型配置示例与工作流一个完整的自托管配置可以这样组合{ // 匹配 MODULE.bazel 文件自动启用 bazel-module manager默认即开启 // 仅在需要锁定文件更新时放行 bazel mod deps 命令 allowedUnsafeExecutions: [bazelModDeps], // 可选为 Bazel 模块依赖指定额外的私有注册表 // 也可以在仓库 .bazelrc 中通过 --registry 声明Renovate 会自动读取 }典型的更新流程如下Renovate 扫描仓库发现MODULE.bazel含lib/modules/manager/bazel-module/index.ts中的匹配模式/(^|/|\\.)MODULE\\.bazel$/extract.ts 解析其中的bazel_dep、override、maven.*、oci.pull、rules_img pull、crate.spec、git_repository等声明并读取.bazelrc补充注册表依据各依赖类型对应的数据源BCR、Maven、Docker、crates.io、GitHub Tags查询新版本生成更新 PR修改MODULE.bazel中的版本号/tag/digest若满足白名单与锁文件前提执行bazel mod deps --lockfile_modeupdate同步更新MODULE.bazel.lock。十一、测试与验证该 manager 的每个解析分支都有对应的单元测试可作为你验证行为或排查问题的参考extract.spec.ts覆盖MODULE.bazel依赖提取与.bazelrc注册表读取artifacts.spec.ts 与 lockfile.spec.ts覆盖锁文件更新、白名单拦截、失败处理等场景rules.spec.ts、rules-img.spec.ts、bazelrc.spec.ts 以及 parser 下的maven/oci/crate/starlark测试逐一验证各类依赖的解析与转换结果。仓库中的测试夹具fixtures/extract/multiple-bazelrcs展示了包含多个.bazelrc文件时注册表配置如何被递归读取与合并。你可以基于这些测试用例理解 Renovate 对复杂MODULE.bazel文件的解析边界例如变量名前缀限制maven*/crate*、扩展名严格限定oci等约定。小结bazel-module是 Renovate 面向 bzlmod 生态的一站式依赖管理方案它同时覆盖 Bazel 模块bazel_dep与各类 override、Maven 构件maven.install/maven.artifact、OCI 镜像oci.pull与rules_img的pull、Rust cratecrate.spec以及 Git 仓库依赖并具备完整的MODULE.bazel.lock锁文件更新能力。在使用时需要留意两条约定模块扩展变量命名maven*、crate*、oci与allowedUnsafeExecutions白名单中的bazelModDeps开关——配置好这两点你的 Bazel 工作区即可实现全自动的依赖升级与锁文件同步。【免费下载链接】renovateHome of the Renovate CLI: Cross-platform Dependency Automation by Mend.io项目地址: https://gitcode.com/GitHub_Trending/re/renovate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
