请求级流水线是什么
GitLab 可以为合并请求单独运行一条流水线：它只在合并请求上下文触发，结果直接显示在请求页面上。这样做既减少重复跑分支流水线，也让「这条请求是否通过检查」和评审页面上的状态保持一致，不必再去别处对照。
基本信息
| 用途 | 针对合并请求运行检查，结果直接反映在请求页面 |
|---|---|
| 常用规则 | 只在流水线来源为合并请求事件时运行 |
| 进阶用法 | 合并结果流水线会在目标分支最新代码上验证 |
| 配合设置 | 分支保护里可要求流水线必须成功 |
典型使用场景
- 每个合并请求都跑一套检查，并把状态显示在请求页面
- 避免同一份提交同时触发分支流水线与请求流水线
- 用合并结果流水线验证合入目标分支之后的结果
- 把流水线成功设为受保护分支的合并前提
- 按请求粒度控制资源消耗
流水线规则示例
流水线规则示例
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event' # 仅合并请求上下文触发
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 主干提交仍然运行触发来源读法
| 来源 | 触发时机 | 适用 |
|---|---|---|
| 合并请求事件 | 创建或更新请求时 | 请求级检查 |
| 提交分支 | 分支上有新提交时 | 主干与长期分支 |
| 合并结果 | 在目标分支最新代码上试跑 | 验证合并之后的结果 |
启用请求流水线之后，可以把分支保护设置为「流水线必须成功」，把检查结果与合并条件绑定起来。
不同类型流水线的变量与凭据范围不同，调试脚本时先确认自己看的是哪一条，否则很容易得出错误结论。
落地步骤
- 先在流水线的顶层规则里限定触发来源
- 把请求级检查与主干检查分开定义，避免重复触发
- 在分支保护中要求流水线成功才能合并
- 观察一段时间的配额消耗，再决定是否启用合并结果验证