GitLab CI的trigger功能是通过API调用实现跨项目流水线自动触发的核心机制，依赖Trigger Token（一次性门禁卡）、目标项目API端点及明确的触发策略，支持curl命令或YAML中trigger关键字两种调用方式，并需下游项目配置workflow规则与变量声明以正确响应。
GitLab CI 的 trigger 功能是实现跨项目自动化联动的核心机制，本质是通过 API 调用让一个项目的流水线主动“唤醒”另一个项目的流水线。它不是魔法，而是一套有明确凭证、路径和规则的通信协议。
拿到并安全使用 Trigger Token
这是触发成功的前提，相当于目标项目的“一次性门禁卡”：
- 进入被触发项目（比如
payment-service）→ Settings → CI/CD → Pipelines triggers → Add trigger，填写描述后生成 Token - Token 只显示一次，必须立即复制保存；切勿硬编码在
.gitlab-ci.yml中 - 推荐做法：在源项目（如
order-service）的 CI/CD Variables 里添加名为OTHER_PROJECT_TOKEN的变量，勾选 Masked 和 Protected
用 curl 或 trigger 关键字发起调用
有两种主流方式，适用不同场景：
-
API 方式（适合灵活控制或调试）：在作业末尾用
curl向目标项目发送 POST 请求curl -X POST \<br> -F "token=$OTHER_PROJECT_TOKEN" \<br> -F "ref=main" \<br> -F "variables[VERSION]=$CI_COMMIT_TAG" \<br> "https://gitlab.example.com/api/v4/projects/456/trigger/pipeline"
-
YAML trigger 关键字（适合声明式编排）：直接在源项目流水线中定义下游依赖
deploy:<br> stage: deploy<br> trigger:<br> project: group/payment-service<br> branch: main<br> strategy: depend
其中strategy: depend表示等待下游完成再标记本阶段成功
确保下游能正确接收和响应
被触发项目需要明确“谁可以来、来干什么、怎么处理参数”：
- 在下游项目的
.gitlab-ci.yml中，可通过workflow:rules控制只响应 trigger 调用：workflow:<br> rules:<br> - if: '$CI_PIPELINE_SOURCE == "pipeline"'<br> when: always - 若需传递参数（如版本号、环境名），上游用
variables[KEY]格式传入，下游需在 job 中显式声明同名变量才能读取 - 注意分支匹配：上游传的
ref必须是下游项目真实存在的分支或 tag，否则触发失败
调试常见问题不踩坑
实际落地时，多数失败集中在三类地方：
- 404 错误：检查项目 ID 是否准确（不是项目名，也不是 URL 路径，而是 Settings → General 页面顶部显示的数字 ID）
- 403 Forbidden：Token 失效、未启用、或权限不足（确保触发方有下游项目的 Reporter 或以上权限）
-
变量没生效：确认上游用了
variables[ENV]=staging格式，且下游 job 中写了ENV: $ENV或直接引用$ENV
