MongoDB 的 Evergreen CI 配置体系项目、组件化 YAML 与发布分支流程【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo本文基于 MongoDB 官方开源仓库The MongoDB Database中的 docs/evergreen-testing/yaml_configuration/configuration.md 文档系统讲解 MongoDB 如何在 Evergreen 持续集成平台上组织mongodb-mongo-master、mongodb-mongo-master-nightly、sys_perf三个 CI 项目剖析etc/evergreen.yml、etc/evergreen_nightly.yml、etc/system_perf.yml的组件化配置结构并完整还原其发布分支Release Branching的变体取舍策略。读完本文你将掌握 MongoDB 仓库中 Evergreen 项目配置的完整脉络、各配置文件之间的引用关系以及为发布分支裁剪构建变体的实操方法。一、Evergreen 与 MongoDB 的 CI 概览Evergreen 是 MongoDB 团队自研并开源的持续集成Continuous Integration, CI系统其核心概念包括Project一个 CI 项目的配置单元绑定特定分支与配置文件Build Variant构建变体对应一种编译或测试环境如操作系统、架构、编译选项的组合Task构建变体内运行的具体任务通常一个任务运行一个或多个测试Patch针对开发者提交的补丁patch触发的验证运行Expansions配置中的变量占位符形如${key|default}运行时由执行器解析。MongoDB 的主仓库通过一套组件化 YAML 配置体系驱动 Evergreen将任务tasks、函数functions、构建变体buildvariants拆分为多个独立 YAML 组件再通过 Evergreen 的include机制合并进顶层项目配置文件。这套体系的核心目标是在 master 分支开发与发布分支release之间复用尽可能多的配置同时允许按需裁剪。术语细节可参考 Evergreen 官方的 Project Configuration 文档Evergreen wiki本文聚焦 MongoDB 仓库内的实际配置实现。二、Evergreen 项目Projects布局MongoDB 的 CI 由多个 Evergreen 项目协同支撑其中三个核心项目定义在关联文档中2.1mongodb-mongo-masterMongoDB 开发环境测试的主项目。它包含大量构建变体每个变体对应一种特定的编译或测试环境用于支撑日常开发。每个构建变体会运行一组任务每个任务通常运行一个或多个测试例如 resmoke 测试套件、单元测试、编译任务、代码检查任务等。项目配置文件etc/evergreen.yml定位开发主力包含所有功能相关feature-specific、补丁构建必需patch build required以及建议suggested的变体。2.2mongodb-mongo-master-nightly与mongodb-mongo-master跟踪同一条分支但每个构建变体对应一个受支持的 MongoDB nightly 版本的(version, OS, architecture) 三元组即面向公开 nightly 发布构建。项目配置文件etc/evergreen_nightly.yml定位仅包含公开 nightly 构建所需的变体例如亚马逊、Debian、IBM、macOS、RHEL、SUSE、Ubuntu、Windows 等平台的test_release.yml变体。2.3sys_perf系统性能测试项目system performance project负责 MongoDB 的系统级性能基准测试。项目配置文件etc/system_perf.yml。三、项目配置文件体系Project Configurations上述 Evergreen 项目由以下配置文件定义构成了 MongoDB CI 配置的完整骨架配置文件对应 Evergreen 项目职责etc/evergreen_yml_components/**.yml全部存放任务、函数、构建变体等定义的 YAML 组件由原evergreen.yml拆分而来etc/evergreen.ymlmongodb-mongo-master导入组件包含全部开发用构建变体etc/evergreen_nightly.ymlmongodb-mongo-master-nightly仅含公开 nightly 构建变体导入与evergreen.yml相似的组件以保持一致etc/system_perf.ymlsys_perf系统性能项目的配置3.1etc/evergreen_yml_components组件化拆分etc/evergreen_yml_components目录存放从原evergreen.yml中拆分出来的 YAML 组件涵盖任务定义、函数定义、构建变体定义等。这些组件文件通过 Evergreen 的include特性被合并进顶层配置文件。从仓库引用看etc/evergreen.yml 与 etc/evergreen_nightly.yml组件按功能目录组织configuration.yml、definitions.yml基础配置与公共定义tasks/compile_tasks*.yml编译类任务tasks/resmoke/...按服务团队划分的 resmoke 测试任务如clusters_and_integrations、durable_transactions_and_availability、query、non_server_teamstasks/misc_tasks.yml、tasks/security_tasks.yml、tasks/coverity_tasks.yml、tasks/release_tasks.yml杂项、安全、静态分析、发布任务variants/平台/test_dev.yml/test_release.yml按平台amazon、macos、rhel、ubuntu、windows、debian、ibm、suse 等或变体分组sanitizer、mongot、codecoverage、wiredtiger、coverity、release组织的构建变体定义custom_builds/自定义构建的任务与变体copybara/copybara.yml与外部仓库同步的 copybara 相关配置。需要说明的是该目录在当前开源仓库快照中并未直接检出其内容由 MongoDB 内部同步机制维护仓库中的buildscripts/tests/test_sync_repo_with_copybara.py会校验相关文件的同步规则但其文件名与路径在 etc/evergreen.yml 和 etc/evergreen_nightly.yml 中被大量include引用读者可据此还原完整的组件树。变体文件的组织约定详见 buildvariants.md。3.2etc/evergreen.ymlmaster 项目配置etc/evergreen.yml是mongodb-mongo-master的项目配置其头部注释详尽说明了本仓库的 YAML 编写约定etc/evergreen.ymlExpansions变量展开机制Expansions 通常写作${key|default}形式若执行器executor的展开变量映射中存在key则使用对应值否则使用default。任意 expansions 可在以下字段中定义expansions字段针对 buildvariant位于分支文件中expansions字段针对 distro位于 distros 文件中。此外还有一批内置 expansions 可用包括宿主机上的环境变量workdir执行器的工作目录task_id执行器正在处理的任务 IDbuild_variant正在执行任务的构建变体名config_root执行器配置产物的根目录。新任务的环境搭建文件注释给出了两类新任务环境搭建的标准函数调用序列若任务依赖archive_dist_test/archive_dist_test_debug任务可直接调用do setup函数或者按序调用fetch artifacts→f_expansions_write→kill processes→cleanup environment→set up venv若任务不依赖上述归档任务则按序执行manifest.load→git get shallow project克隆完整 mongo 与 enterprise 仓库→restore git history and tags→f_expansions_write→kill processes→cleanup environment→set up venv。include 组件引用主配置通过include逐项导入组件文件etc/evergreen.yml涵盖基础定义、编译任务、resmoke 任务、各平台开发变体、Atlas 模块配置src/mongo/db/modules/atlas/atlas_dev.yml等、copybara 配置以及 monguard 安全配置monguard/.evergreen/...。parameters参数evergreen.yml声明了一批参数etc/evergreen.yml例如evergreen_config_file_path值为etc/evergreen.yml指向本文件路径test_selection_strategies_array测试选择策略数组use_tss_staging置为 true 时使用 staging 测试选择部署runtime_params_json基准测试任务的运行时参数 JSON例如{enable_linux_perf:true}用于开启 on-CPU profilingantithesis_suites逗号分隔的 ds-antithesis 套件任务用于针对该 patch 的 mongod 镜像运行为空或未设置则不触发message_filter_plugin_release_versionmessage filter 插件的 dev 版本字符串形如YYYYMMDD.hhmmss.githash用于 GA 推广。Aliases别名commit_queue_aliasesetc/evergreen.yml定义提交队列变体上运行的匹配任务如commit-queue变体匹配bazel_.*、run_.*、unit_test.*、compile_.*、lint_.*、resmoke_tests等任务github_pr_aliasesetc/evergreen.ymlGitHub PR 触发的别名结构与提交队列相似patch_aliasesetc/evergreen.ymlpatch 验证别名例如required通过variant_tags: [required]选择所有必需变体query、query-quick、query-joo、security按变体正则选择对应的 patch-only 变体bazel/bazel_variants运行 Bazel 构建系统测试search运行所有$search、$vectorSearch相关测试required-and-mongot-e2e-tests选择所有必需变体 使用真实 mongot 的变体中的任务codecoverage/unittestcoverage代码覆盖率任务disagg从每个必需变体中提取 DSCdisaggregated测试是required的严格子集。3.3etc/evergreen_nightly.ymlnightly 项目配置etc/evergreen_nightly.yml用于 release 构建etc/evergreen_nightly.yml。它与evergreen.yml导入相似的组件以确保一致性但存在明显差异发布组件额外导入tasks/compile_tasks_nightly.yml、tasks/coverity_tasks.yml、variants/coverity.yml、tasks/release_tasks.yml、custom_builds/、Atlas 发布配置src/mongo/db/modules/atlas/atlas_release.yml平台差异使用各平台的test_release.ymlamazon、debian、ibm、macos、rhel、suse、ubuntu、windows而非test_dev.yml开发组件被注释variants/misc/misc.yml、各平台test_dev.yml、sanitizer/test_dev.yml、mongot/test_dev.yml、variants/release/release.yml等均以注释形式保留并标注 Uncomment when using this file for a release branch.——即发布分支release branch场景下按需取消注释参数与别名声明evergreen_config_file_path etc/evergreen_nightly.yml并定义了coverity_scan、release_smoke_test匹配crypt_create_lib|package|test_packages|jscore、blocking-emergency-atlas-release-tasks通过variant_tags: [emergency_release]等发布相关别名。3.4etc/system_perf.yml性能项目配置sys_perf项目的配置非常轻量etc/system_perf.ymlmodules声明依赖 DSI 模块owner: 10gen、repo: dsi、prefix: ${workdir}/src、branch: masterinclude导入 DSI 仓库内的性能配置组件如evergreen/system_perf/master/base.yml、compiles.yml、compiles_pgo.yml、variants.yml、master_variants.yml、shared_tasks.yml。值得注意的是文件中的lint_yaml trim start/end注释说明这些引用 DSI 仓库的行会被yamllinters.sh裁剪以便evergreen evaluate能对非 DSI 的导入继续工作详见 buildscripts/yamllinters.py。同时etc/evergreen_yml_components/variants下的部分变体文件也可能被复用合并进system_perf.yml。四、配置的校验、lint 与评估MongoDB 的 Evergreen 配置并非直接裸奔上线而是有完整的校验链路4.1evergreen evaluate预处理buildscripts/ciconfig/evergreen.py中的parse_evergreen_file会调用evergreen evaluate path命令预处理项目配置文件evergreen.py该命令负责展开include与 expansions将组件合并为完整的最终配置随后加载为EvergreenProjectConfig实例供 CI 工具链使用。evergreen可执行文件可通过环境变量或默认位置发现若找不到会抛出EnvironmentError。4.2 Evergreen lint 规则仓库提供了 etc/evergreen_lint.yml 定义配置 lint 规则作用于evaluated_evergreen.yml与evaluated_evergreen_nightly.yml两个评估产物代表性规则包括limit-keyval-inc限制 YAML 中keyval.inc命令的数量上限 5no-working-dir-on-shell禁止在 shell 任务中使用working_dir参数要求先 sourceprelude.sh且位于${workdir}no-multiline-expansions-update禁止多行expansions.updateinvalid-build-parameter要求参数名匹配[a-z][a-z0-9_]*且必须有非空描述防止未经文档化的构建参数泛滥required-expansions-write要求evergreen/*.sh脚本调用expansions.write避免 prelude.sh 加载过期的 expansions。补充etc/evergreen_lint.yml中的files路径相对配置文件所在目录lint 的完整执行流程可参考 buildscripts/lint_yaml.sh 等脚本。五、发布分支流程Release Branching Process关联文档明确规定了 MongoDB 发布分支时 Evergreen 项目的变体取舍原则仅mongodb-mongo-master-nightly项目随发布分支分支并加回必需变体及其他必要变体如 sanitizersmongodb-mongo-master中的大多数变体默认被丢弃但可根据需要手动将个别变体重新引入发布分支对于 Rapid releases快速发布mongodb-mongo-master-nightly中除与 Atlas 相关的变体外其余变体也可能一并丢弃。这一策略在配置文件层面有直观的落地体现etc/evergreen_nightly.yml 中所有开发专用组件test_dev.yml、misc.yml、sanitizer/test_dev.yml、mongot/test_dev.yml、variants/release/release.yml都被注释并明确标注 Uncomment when using this file for a release branch.使用本文件作为发布分支配置时取消注释而 buildvariants.md 中的变体文件约定表进一步细化了分支前后的行为YAML 文件运行位置master 项目与 YAMLrelease 项目与 YAMLtest_dev.ymlmaster releasesmongodb-mongo-master/evergreen.ymlmongodb-mongo-vX.Y/evergreen_nightly.ymltest_dev_master_branch_only.yml仅 mastermongodb-mongo-master/evergreen.yml不使用test_release.ymlmaster releasesmongodb-mongo-master-nightly/evergreen_nightly.ymlmongodb-mongo-vX.Y/evergreen_nightly.ymltest_release_master_branch_only.yml仅 mastermongodb-mongo-master-nightly/evergreen_nightly.yml注释掉由此可以推断分支时实际发生的是——以evergreen_nightly.yml为基础按需取消注释加回 sanitizer、release 等必要变体并启用test_release.yml系列文件从而生成mongodb-mongo-vX.Y项目的配置而mongodb-mongo-master的开发变体则不再跟随分支。六、构建变体补充知识为了理解上述配置文件中的变体语义这里补充关联系列文档 buildvariants.md 中的关键约定必需变体Requireddisplay name 前带!的构建变体同时带有requiredtag对应补丁构建必需策略建议变体Suggesteddisplay name 前带*的构建变体同时带有suggestedtagforbid_tasks_tagged_with_experimentaltag带此 tag 的构建变体不允许运行标记为experimental的任务该限制由forbid-tasks-with-tag-on-variantsEvergreen lint 规则强制执行变体文件组织etc/evergreen_yml_components/variants下的子目录多为平台名amazon、rhel 等或变体分组名sanitizer 等部分文件可被sys_perf项目复用。七、延伸阅读Evergreen 测试总览构建变体详解任务所有权标签任务选择标签任务生成机制resmoke 套件的 Bazel 执行配置评估工具链源码【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
