Origin 接入现有 CI 流程的配置与错误排查

Origin 作为代码仓库接入现有 CI，核心是让仓库事件通过 webhook 投递到 CI 的接收端点。对接是否成功，最终不看 Origin 后台的 webhook 列表，而要看 CI 侧收到的请求日志。配置时抓住 URL、事件类型、secret token 三项，排查时按签名、超时、解析三类日志特征逐项处理。

接入现有 CI 时，适用场景是已有 GitLab CI 或 GitHub Actions 的团队。处理方向：在 Origin 项目设置中创建 webhook，填写 CI 接收地址和触发事件，用 secret token 校验请求；验证方式是用 curl 模拟推送并查看 CI 接收日志；风险边界：Origin 不提供内置 CI 能力，所有构建触发依赖 webhook 送达，超时和签名错误需要分别从网络和配置两侧排查。

在 Origin 仓库设置中创建 webhook

进入 Origin 项目页面后，在左侧或顶部导航中找到 Settings 或设置，进入 Webhooks 菜单。点击 Add webhook 或 Create webhook，会出现表单。URL 处填写 CI 系统对外开放的接收地址，这个地址通常由 CI 平台生成，以 /webhook 或 /origin 结尾。触发事件中，push 是最基本的选项，必须勾选；如果合并请求也需要触发流水线，再勾选 merge request。保存后，webhook 记录会出现在列表中，部分 Origin 版本会显示最近一次投递状态，但只有 CI 侧的访问日志才是最终依据。

生成 secret token 并在 CI 侧校验请求

在同一个 webhook 表单中，Secret 字段用于生成签名。保存前从这里复制或手动生成一段随机字符串，放到 CI 系统环境变量里。Origin 发送请求时会用该 secret 对请求体计算签名，并放进某个请求头。CI 端需要从原始请求体字节计算签名再比对，不能使用解码后的 JSON 或 proxy 处理过的结构。以下是一个可用的校验骨架：

import hmac, hashlib

def verify_origin_signature(payload, secret, signature):
    if not signature:
        return False
    expected = hmac.new(secret.encode(), payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest("sha256=" + expected, signature)

注意签名头名称和签名前缀需从实际请求日志中确认。例如有些系统使用 X-Signature，格式为 sha256=<value>；如果日志显示的是其他前缀，调整对应部分即可。CI 服务启动时，从环境变量读取 secret，避免写死在代码里。如果 secret 泄露，在 Origin 和 CI 两侧同时更换。

用 curl 模拟 webhook 验证连通性

为了不依赖真实推送，可以先在本地模拟一条 webhook。执行以下命令（替换 URL 和负载）：

curl -X POST https://ci.example.com/webhook/origin \
  -H "Content-Type: application/json" \
  -H "X-Origin-Event: push" \
  -d '{"ref":"refs/heads/main","repository":{"name":"demo"}}'

如果 CI 端开启了签名校验，临时关掉它，或者先计算好签名再添加请求头；首次验证建议先不带签名，确认网络链路。发送后立刻查看 CI 接收日志。关键字段有：请求方法（POST）、状态码（2xx 或 4xx）、事件类型、仓库名。如果日志中完全没有这一条请求，检查 curl 返回的响应码和网络连通性。

根据 CI 日志定位签名错误或超时问题

常见的 webhook 失败集中在三类，日志特征和调整方向如下：

签名不匹配：日志中出现 invalid signature 或 signature mismatch。在 Origin 侧重新复制 secret token，检查是否混入空格；CI 侧检查环境变量值是否一致，确认签名算法和原始请求体是否一致。如果代理层修改过 body，需要让 CI 读取原始 body。
超时：日志中出现 timeout 或 timed out。CI 侧先检查接收服务是否能快速响应；如果 CI 处理逻辑本身超过几秒，可以在 webhook 配置中调大超时时间，或者将接收端点改为先返回 200 再异步处理。
payload 解析失败：日志中出现 invalid payload 或 parse error。CI 侧检查 Content-Type 是否 application/json，以及请求体是否合法 JSON；Origin 侧确认所选事件类型实际推送的字段与 CI 解析逻辑匹配，可在首次请求时打印原始 payload 再调整解析代码。

这三类问题大多能在 CI 日志中直接定位到具体错误行，先修签名和超时，再处理字段结构，可以减少重复试错。