DAG 依赖是干什么的
用依赖图替代整阶段等待:作业只等自己真正需要的上游,关键路径缩短,反馈更快。GitLab 用 needs 指定上游作业,可跨阶段提前运行;GitHub Actions 用作业级 needs 构成 DAG,未声明依赖的作业并行执行。效果是阶段内并行加阶段间解耦,整体时长按关键路径收敛。注意 needs 同时限定作业可见的产物集合:引用未声明依赖的产物会在流水线早期报错。
基本信息
| GitLab | needs 指定上游作业,可跨阶段提前运行 |
|---|---|
| GitHub | 作业级 needs 构成 DAG,未列依赖的作业并行 |
| 效果 | 阶段内并行加阶段间解耦,时长按关键路径收敛 |
| 产物边界 | needs 同时限定可见的制品集合 |
| 空依赖 | needs 为空列表表示流水线开始即可运行 |
典型使用场景
- 长流水线压缩:把全部测试等待全部构建,改成每个测试只等自己的构建。
- 快速反馈:lint 无上游依赖,流水线开始即运行,几秒出结果。
- 多服务仓库:按服务拆分依赖关系,改一个服务不拖慢其他服务。
- 可视化核对:流水线图上箭头即依赖,评审配置时直观检查。
- 失败影响面控制:上游失败只影响依赖它的作业,无关作业继续跑完。
- 关键路径优化:先测量最长依赖链,再针对性加并行或拆分。
GitLab needs
GitLab needs
test:app:
stage: test
needs: ["build:app"] # 只等应用构建,不等整个阶段
script: make test-appGitHub needs
GitHub needs
jobs:
test:
needs: build # 构成 DAG 边
runs-on: ubuntu-latestneeds 会限定作业可见的产物集合;引用未声明依赖的产物会在早期报错,报错本身是保护。
DAG 不是越扁平越好:大量作业同时开跑会争抢运行器与共享资源,要配合并发上限与资源组使用。
上游失败时下游依赖作业会被取消:想尽量多收集结果的检查不要挂严格依赖,或允许失败单独收集。