如何在GitLab Webhook URL中传递源仓库分支名触发跨仓库流水线

你当前配置失效的核心原因是：GitLab项目设置中的Webhook配置页属于静态配置入口，不会解析CI流水线内置的${CI_COMMIT_REF_NAME}这类运行时预定义变量。你直接把变量拼接在Webhook触发URL中，传到repo B的永远是未替换的字面量字符串，自然无法获取repo A触发时对应的真实分支名。

• 方案1：在repo A的CI任务内调用触发接口（稳定性最高，最常用）
  不要在项目Webhook设置面板配置触发规则，直接在repo A的.gitlab-ci.yml中新增触发任务，CI运行环境会自动完成变量解析替换，示例配置：

  trigger_repo_b_pipeline:
    stage: post_deploy # 按需替换为你实际的流水线阶段
    script:
      - >
        curl --request POST
        --form "token=${REPO_B_TRIGGER_TOKEN}"
        --form "ref=dev"
        --form "variables[WEBHOOK_BRANCH]=${CI_COMMIT_REF_NAME}"
        "${CI_API_V4_URL}/projects/<repoB的数字项目ID>/trigger/pipeline"
    only:
      - pushes
      - merge_requests
  

  提前在repo A的CI/CD变量设置中存入repo B的流水线触发令牌，变量名设为REPO_B_TRIGGER_TOKEN，同时开启掩码、受保护选项避免令牌泄露。配置完成后repo B的流水线可以直接通过$WEBHOOK_BRANCH读取到repo A的触发分支名。
• 方案2：使用GitLab原生多项目流水线触发（无额外脚本，配置最简）
  直接用GitLab内置的trigger关键字实现跨仓库流水线触发，不需要手写curl请求，变量传递由GitLab原生支持，示例配置：

  trigger_repo_b_pipeline:
    stage: post_deploy # 按需替换为你实际的流水线阶段
    trigger:
      project: <repoB的完整路径，例如engineering/backend/service-b>
      branch: dev
    variables:
      WEBHOOK_BRANCH: ${CI_COMMIT_REF_NAME}
  

  该方案需要确保repo A的CI运行用户有repo B的流水线触发权限，配置完成后repo B侧可直接读取$WEBHOOK_BRANCH变量。
• 方案3：必须使用项目级Webhook时增加中转解析层
  如果你的场景要求必须在项目Webhook面板配置触发规则，不能修改repo A的CI文件，就不要将Webhook请求直接发送到repo B的触发接口。可以先将请求发送到一个轻量中转服务，解析GitLab Webhook请求体自带的ref字段（GitLab发出的Webhook Payload默认就会携带触发源的分支信息），提取到真实分支名后，再组装参数调用repo B的流水线触发接口，将分支名作为自定义变量传入。

注意：如果repo B的目标分支是受保护分支，要确保触发使用的令牌、关联用户有对应受保护分支的流水线运行权限，否则会出现触发失败、自定义变量丢失的问题。

内容的提问来源于stack exchange，提问作者txyh