如何配置BitBucket Webhook按分支触发对应Google Cloud Build？

一、原生集成方案（无需中间层，推荐） #

Google Cloud Build（GCB）本身支持与BitBucket直接对接，无需通过Cloud Function转发，可直接通过Webhook实现分支与触发器的绑定：

1. 多Webhook对应多触发器（更清晰易维护） #

针对dev、staging、prod三个环境，分别在BitBucket仓库配置3个独立Webhook：

• 触发规则：每个Webhook仅勾选对应分支的推送事件（比如dev分支的Webhook只监听refs/heads/dev的代码推送）
• Payload URL：填写对应GCB触发器的专属Webhook地址，格式为：

  https://cloudbuild.googleapis.com/v1/projects/[你的GCP项目ID]/triggers/[触发器ID]:webhook?key=[你的GCP API密钥]
  

  其中触发器ID可在GCB控制台的触发器详情页获取，API密钥需在GCP控制台「API和服务→凭据」中创建
• 校验配置：Content Type选application/json，设置与GCB触发器一致的Secret Token，用于验证请求合法性

2. 单Webhook配合GCB分支过滤 #

如果偏好单个Webhook，可在BitBucket设置1个监听全部分支推送的Webhook，Payload URL可指向任意一个GCB触发器的Webhook地址，然后在每个GCB触发器中配置分支匹配规则：

• dev触发器：仅匹配dev分支
• staging触发器：仅匹配staging分支
• prod触发器：仅匹配prod分支
  GCB会自动根据推送的分支，触发对应的环境构建任务。

二、Cloud Function中间层方案的评价 #

你当前采用的Cloud Function转发方案并非最优选择，原因如下：

• 额外增加运维成本：需要维护Cloud Function的代码、权限、日志，排查问题多了一层环节
• 引入不必要的延迟：请求多经过一次转发，会拖慢CI/CD流程的响应速度
• 复杂度冗余：GCB原生已支持分支过滤与BitBucket直接集成，完全能满足基础的分支触发需求

只有当你需要实现GCB原生不支持的自定义逻辑（比如复杂分支规则、多仓库联动、前置校验等）时，Cloud Function中间层才具备实用价值。

内容的提问来源于stack exchange，提问作者Rui Bras Fernandes