首页/开发/CI/CD 与发布速查/DAG 依赖加速(needs)
流水线设计54 条

DAG 依赖加速(needs)

用依赖图替代「整阶段等待」:作业只等自己真正需要的上游,关键路径缩短,反馈更快。

CI/CD 与发布速查开发更新于 2026-10-13

DAG 依赖是干什么的

用依赖图替代整阶段等待:作业只等自己真正需要的上游,关键路径缩短,反馈更快。GitLab 用 needs 指定上游作业,可跨阶段提前运行;GitHub Actions 用作业级 needs 构成 DAG,未声明依赖的作业并行执行。效果是阶段内并行加阶段间解耦,整体时长按关键路径收敛。注意 needs 同时限定作业可见的产物集合:引用未声明依赖的产物会在流水线早期报错。

基本信息

GitLabneeds 指定上游作业,可跨阶段提前运行
GitHub作业级 needs 构成 DAG,未列依赖的作业并行
效果阶段内并行加阶段间解耦,时长按关键路径收敛
产物边界needs 同时限定可见的制品集合
空依赖needs 为空列表表示流水线开始即可运行

典型使用场景

  • 长流水线压缩:把全部测试等待全部构建,改成每个测试只等自己的构建。
  • 快速反馈:lint 无上游依赖,流水线开始即运行,几秒出结果。
  • 多服务仓库:按服务拆分依赖关系,改一个服务不拖慢其他服务。
  • 可视化核对:流水线图上箭头即依赖,评审配置时直观检查。
  • 失败影响面控制:上游失败只影响依赖它的作业,无关作业继续跑完。
  • 关键路径优化:先测量最长依赖链,再针对性加并行或拆分。

GitLab needs

GitLab needs
test:app:
  stage: test
  needs: ["build:app"]   # 只等应用构建,不等整个阶段
  script: make test-app

GitHub needs

GitHub needs
jobs:
  test:
    needs: build          # 构成 DAG 边
    runs-on: ubuntu-latest
needs 会限定作业可见的产物集合;引用未声明依赖的产物会在早期报错,报错本身是保护。
DAG 不是越扁平越好:大量作业同时开跑会争抢运行器与共享资源,要配合并发上限与资源组使用。
上游失败时下游依赖作业会被取消:想尽量多收集结果的检查不要挂严格依赖,或允许失败单独收集。

易错点

  • 只按 needs 拆解却忽略资源竞争:大量作业同时抢占运行器反而排队,应配合并发上限。
  • needs 指向的作业因规则未生成:报需要的作业不存在,依赖与规则要联动调整。
  • 用 needs 提前运行但产物未就绪:确认依赖真实成立再运行,否则下游读到旧产物。
  • 依赖链长且中间环节慢:关键路径没压缩多少,先测量再改图。
  • 忽略失败传播:上游失败会让下游整批取消,检查项之间的依赖关系要按收集需要来设计。

数据来源与参考

  • GitLab Docs《Needs》
  • GitHub Docs《Using jobs》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌