单仓多项目流水线是什么
单仓多项目流水线要回答一个问题：这次提交影响了哪些项目，只构建它们。基础手段是路径过滤加目录级子管道或作业分组；进阶用依赖图工具（Nx affected、Turborepo、Bazel query）基于图挑选目标。关键难点是传递影响：共享库改了，所有消费者都要重跑——路径过滤本身不知道这层关系，要靠工具或维护好的依赖清单补齐。
基本信息
| 基础手段 | 路径过滤 + 目录级子管道或作业分组 |
|---|---|
| 进阶工具 | Nx affected、Turborepo、Bazel query 基于依赖图挑选目标 |
| 收益 | 全仓单管道改为按需执行，时长与资源显著下降 |
| 易漏点 | 共享库到消费者的传递依赖，路径过滤覆盖不到 |
按需执行的判断依据
| 变更位置 | 需要构建 | 说明 |
|---|---|---|
| apps/web/* | web 及其依赖 | 常规路径过滤即可 |
| libs/shared/* | 全部消费者工程 | 传递影响，靠依赖图 |
| 顶层配置 | 全部项目 | CI 配置、根锁文件变更 |
| 文档与注释 | 跳过构建 | 保留轻量检查 |
典型使用场景
- 大仓拆分构建：每个子项目独立作业，按路径变化触发
- 传递影响计算：共享库变更时按依赖图放大触发范围
- 资源优化：避免全仓全量构建，缩短合并请求反馈时间
- 发布编排：按项目独立版本与发布节奏，只发布受影响服务
- 变更可视化：把将执行哪些项目生成摘要贴到合并请求
- 新人理解成本：把影响范围与触发规则写进仓库说明，减少为什么没跑我改的模块的困惑
GitLab 按目录分派
GitLab 按目录分派
web:test:
rules:
- changes: [web/**/*]
script: cd web && npm test
# 共享库变更触发全部消费者（实际由依赖图工具生成目标）
shared:verify:
rules:
- changes: [libs/shared/**/*]
script: ./ci/test-consumers.sh依赖图要覆盖共享库到消费者的传递影响，否则会漏跑。
顶层文件（CI 配置、根锁文件）变更时稳妥做法是触发全量构建：宁可多跑，不可漏跑。