GitHub/GitLab 开发者自动化

第 12 章：GitHub / GitLab 开发者自动化

代码仓库是工程团队最核心的协作枢纽，但 GitHub/GitLab 本身的通知机制过于噪杂，且与飞书、Notion 等工具相互割裂。n8n 通过 GitHub Trigger、GitLab Webhook 以及 GitHub / GitLab 操作节点，把代码事件无缝接入团队的协作工作流。本章涵盖触发器配置、PR 自动分配 Reviewer、Issue 状态同步 Notion、CI/CD 状态播报，以及代码审查超时催促四个核心场景。

GitHub Trigger：监听仓库事件

GitHub Trigger 节点通过 GitHub Webhook 机制实时接收仓库事件，无需轮询。n8n 会自动在目标仓库创建 Webhook（需要 Personal Access Token 或 GitHub App 有仓库管理权限）。

常用事件类型

凭证配置

在 n8n Credentials 中创建"GitHub API"凭证，填入 Personal Access Token（需要 repo 和 admin:repo_hook 权限）。激活工作流时，n8n 会自动调用 GitHub API 为目标仓库注册 Webhook，并在工作流停用时自动删除，无需手动管理。

GitLab Webhook：MR 状态变更触发

GitLab 没有像 GitHub 那样的专用 Trigger 节点，而是通过 n8n 的通用 Webhook 节点接收 GitLab 推送的事件。配置步骤：

1. 在 n8n 中创建 Webhook 节点，复制生成的 URL（含唯一路径）
2. 进入 GitLab 项目 → Settings → Webhooks → 填写 URL
3. 勾选需要监听的事件：Push Events、Merge Request Events、Pipeline Events、Issues Events 等
4. 填写 Secret Token（可选，用于验签），在 n8n Code 节点中验证 X-Gitlab-Token 请求头

GitLab MR 事件 Payload 的关键字段：object_kind（值为 merge_request）、object_attributes.state（opened / merged / closed）、object_attributes.title、object_attributes.url、assignee。

实战：PR 创建 → 自动分配 Reviewer → 飞书通知

工程团队常见痛点：PR 创建后，Reviewer 不知道，作者不断催，进度阻塞。n8n 可以完全自动化这个流程。

工作流设计

1. GitHub Trigger：监听 pull_request 事件，Action 过滤为 opened（只处理新建 PR）
2. IF 节点：判断 PR 是否来自 bot 账号（如 dependabot），若是则跳过，避免为自动化 PR 分配 Reviewer
3. Code 节点：实现轮询（Round-Robin）或基于文件路径的负载均衡分配逻辑——读取一个存储在 n8n 静态数据（Static Data）中的"上次分配人"索引，计算本次应分配的 Reviewer
4. GitHub 节点（Request Review）：调用 GitHub API 将 Reviewer 添加到 PR
5. HTTP Request 节点：向飞书发送卡片消息通知 Reviewer，内容包含 PR 标题、描述、变更文件数和 PR 链接

// 飞书 PR 通知卡片 Body（HTTP Request 节点）
{
  "msg_type": "interactive",
  "card": {
    "header": {
      "title": { "tag": "plain_text", "content": "新 PR 待你审查" },
      "template": "blue"
    },
    "elements": [
      {
        "tag": "div",
        "text": { "tag": "lark_md",
          "content": "**{{ $json.pull_request.title }}**\n作者：{{ $json.pull_request.user.login }}\n变更文件：{{ $json.pull_request.changed_files }} 个" }
      },
      { "tag": "action", "actions": [{
        "tag": "button",
        "text": { "tag": "plain_text", "content": "查看 PR" },
        "type": "primary",
        "url": "={{ $json.pull_request.html_url }}"
      }]}
    ]
  }
}

实战：Issue 关闭 → 自动更新 Notion 任务状态

让 GitHub Issue 与 Notion 项目管理数据库保持同步，研发完成后 PM 实时感知进度。

1. GitHub Trigger：监听 issues 事件，在 IF 节点过滤 {{ $json.action }} === "closed"
2. Notion 节点（Get Many）：在任务数据库中搜索 "GitHub Issue Number" 属性等于 {{ $json.issue.number }} 的页面
3. IF 节点：判断查询结果是否为空（Issue 是否已录入 Notion）
4. Notion 节点（Update Page）：将对应任务的 Status 属性更新为"已完成"，Closed At 更新为当前时间
5. HTTP Request 节点：可选——向 PM 飞书发送任务完成通知

CI/CD 状态播报：构建成功/失败推送消息

通过 GitHub Actions 的 workflow_run 事件，实时将构建结果推送到飞书群：

// workflow_run 事件 Payload 关键字段
{
  "action": "completed",
  "workflow_run": {
    "name": "CI",
    "conclusion": "success",  // success | failure | cancelled | skipped
    "head_branch": "main",
    "head_sha": "abc123",
    "html_url": "https://github.com/org/repo/actions/runs/123",
    "run_started_at": "2025-04-25T09:00:00Z",
    "updated_at": "2025-04-25T09:03:42Z"
  }
}

在 IF 节点中根据 conclusion 字段区分成功/失败，分别推送绿色成功卡片或红色失败卡片，并在失败时额外 @oncall 人员。

代码审查提醒：超过 24h 未审查自动催促

这是一个定时检查型工作流，每小时运行一次：

1. Cron 触发器：每小时整点运行
2. GitHub 节点（List Pull Requests）：查询所有 open 状态且有待审查 Reviewer 的 PR
3. Code 节点：计算每个 PR 的创建时间与当前时间之差，筛选出超过 24 小时未合并且未被审查的 PR
4. Loop Over Items 节点：对每个超时 PR 单独处理
5. HTTP Request 节点：发送飞书 @Reviewer 催促消息，消息中包含 PR 名称、等待时长和直达链接

避免重复催促： 在 n8n 静态数据（Workflow Static Data）中维护一个已催促 PR 的 ID 集合，每次运行前检查是否已催促过；若当日已催促则跳过，避免每小时狂轰滥炸。