触发方式总览
流水线触发方式各有适用场景：推送（push）、合并请求（MR/PR）、标签（tag）、定时（schedule）、手动与 API。组合使用才能覆盖日常验证加按需发布：日常验证走 push 与 MR，发布走标签或手动，巡检走定时。原则是把触发条件写在仓库里（GitLab 的 rules、GitHub 的 on），比在平台界面点击配置更可审计；同时避免同一提交被多种触发器重复产生流水线。
常见触发
| push | 分支日常验证 |
|---|---|
| MR/PR | 合入前验证合并结果 |
| tag | 版本发布入口 |
| schedule | 夜间回归与巡检 |
| manual/API | 按需发布与重跑 |
触发与示例
| 触发 | 典型用途 | 示例 |
|---|---|---|
| push 推送 | 分支日常验证 | GitHub 用 on: push |
| merge/pull request | 合入前验证 | GitLab 用 merge_request_event |
| tag 标签 | 版本发布 | GitLab 用 $CI_COMMIT_TAG 判断 |
| schedule 定时 | 夜间回归与巡检 | GitHub 用 on: schedule |
| manual/API | 按需发布与重跑 | GitLab 用 when: manual |
GitLab rules 组合
GitLab rules 组合
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_TAG
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH典型使用场景
- 日常提交：push 触发轻量检查，控制反馈时长。
- 合入前：MR 触发完整验证，防止主干红灯。
- 版本发布：推送 v 系列标签自动进入发布流水线。
- 巡检与回归：定时跑全量测试、依赖检查与清理任务。
- 应急重跑：手动按钮或 API 重跑失败阶段与补偿任务。
- 组合治理：用工作流规则或事件过滤去掉重复触发，例如分支流水线与 MR 流水线并存时收敛。
触发条件写在仓库里（rules 或 on），比在平台上点击配置更可审计，也随代码一起评审。
GitHub 定时任务在默认分支上运行且使用 UTC 时间：切换默认分支会改变行为，需要纳入变更评审。
API 触发使用专用的流水线触发器令牌：个人凭据随人员变动失效，专用令牌可单独审计与吊销。
触发通道安全
- 敏感触发的凭据隔离：发布与部署作业使用专用变量，并限定只在保护分支或标签的流水线中注入。
- 手动触发也应有权限边界：能点发布按钮的开发与能改代码的人分开，环境规则里显式配置允许者。
- 重跑要留下记录：手动重跑与 API 触发都产生审计事件，复盘时能还原谁在何时触发了什么。
定时任务适合承载长耗时与非紧急任务：夜间全量回归、依赖巡检、环境清理，把提交路径留给快速检查。