danswer 仓库自动化评审实战：基于 glab 的 GitLab MR 讨论与流水线 API 速查

danswer 仓库自动化评审实战：基于 glab 的 GitLab MR 讨论与流水线 API 速查

【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer

在 AI 驱动的代码评审自动化场景中，GitLab Merge Request（MR）的讨论（Discussion）、流水线（Pipeline）与评论（Note）数据是判断「代码是否可以合入」的核心依据。本文以 danswer 仓库.cursor/skills/greptile/check-pr技能中使用的 GitLab API 参考 为主线，系统讲解如何用glab api一键拉取 MR 详情、遍历并筛选未解决的 DiffNote 行内评论、逐条解决讨论线程、轮询流水线状态并定位失败 Job，以及如何以 CLI 或 REST 两种方式向 MR 发布评论。读完本文，你将掌握一套可直接复制进脚本或 Agent 工作流中的 GitLab REST API 调用范式，并能对照 GitHub 的等价字段快速迁移。

1. 前置条件：glab 与 :fullpath 占位符

本文所有请求都依赖 GitLab 官方 CLIglab。在运行前需要确保：

• 已安装并登录glab（glab auth login），拥有目标项目的api权限；
• 当前 shell 位于该项目的一个 git 克隆目录内（或通过--repo显式指定项目）。

glab api的核心便利在于会自动把 URL 中的:fullpath占位符解析为从本地 git remote 读取、经 URL 编码后的项目路径，因此无需手写namespace%2Fproject这类转义串。这一设计让 check-pr 技能可以在任意 GitLab 仓库中直接运行而无需感知具体项目名。

2. 拉取 MR 详情：先认准 iid 而非 id

获取一个 MR 的元数据，首选：

glab mr view <MR_IID> --output json

<MR_IID>是该 MR 在项目内的内部编号（Internal ID），在 GitLab 中通常写作!123这样的形式；而id是全局唯一 ID，只在跨项目场景下才有意义。所有讨论、评论、流水线 API 都应以iid为准。

该命令返回的 JSON 中，与 GitHub PR 视图字段的对应关系如下（这也是 check-pr 中「平台字段差异」一节所依赖的映射）：

另外，glab mr view --output json | jq '.iid'也是 check-pr 在未提供 MR 编号时自动探测当前分支对应 MR 的手段。

3. 拉取全部讨论：Discussions 端点与分页

GitLab 把「一个话题」称为 Discussion，其中可以包含多条 Note（评论）。一次性拉取某 MR 的全部讨论：

glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100"

GitLab 的列表接口默认按页返回，因此需要手动分页：在 URL 后追加&page=2、&page=3……直到某次响应返回的数组长度小于per_page（即不足 100 条）为止。在脚本中可以写成循环：

page=1 while :; do result=$(glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100&page=$page") echo "$result" | jq -c '.[]' count=$(echo "$result" | jq 'length') [ "$count" -lt 100 ] && break page=$((page + 1)) done

3.1 讨论对象与 Note 对象结构

每个 Discussion 对象包含三个关键字段：

• id— 讨论 ID，解决线程时要用它；
• resolved—true或false，是否已被解决；
• notes— Note 对象数组（一条讨论可含多条回复）。

每个 Note 对象的核心字段：

• type—"DiffNote"表示行内 diff 评论；null表示普通讨论评论。这是区分「行内待办」与「一般留言」的关键标志；
• author.username— 评论作者；
• body— 评论正文；
• position.new_path— 仅DiffNote类型存在，表示评论所在文件路径。

4. 筛出未解决的行内评论：jq 一行流

结合resolved与notes[0].type两个条件，可以精确过滤出「尚未解决的行内 DiffNote」，这是评审清单的核心数据源：

glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100" | \ jq '[.[] | select(.resolved == false and (.notes[0].type == "DiffNote"))]'

该命令返回一个数组，其中每个元素都带有id、notes[0].body、notes[0].position.new_path，足以生成 check-pr 第五节要求的「Actionable / Informational / Already addressed」分类清单。

5. 解决讨论线程：逐条 PUT，无批量接口

GitLab 与 GitHub 的一个重要差异是：GitHub 可用 GraphQL 别名批量 resolve（见 graphql-queries.md 中的批量 mutation），而 GitLab REST 没有批量解决接口，必须对每个讨论 ID 单独发起一次 PUT。

glab api --method PUT \ "projects/:fullpath/merge_requests/<MR_IID>/discussions/<DISCUSSION_ID>" \ --field resolved=true

在自动化脚本中，把第 4 步筛出的讨论 ID 收集成数组，逐个调用即可：

glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100" \ | jq -r '.[] | select(.resolved == false) | .id' \ | while read -r did; do glab api --method PUT \ "projects/:fullpath/merge_requests/<MR_IID>/discussions/$did" \ --field resolved=true done

这正是 check-pr 第 8 节「Resolve review threads」中 GitLab 分支的实现路径。

6. 流水线状态：等待 CI 到达终态

在分析 MR 前，check-pr 要求先确认 CI 全部结束。GitLab 侧通过 Pipelines 端点轮询：

glab api "projects/:fullpath/merge_requests/<MR_IID>/pipelines"

Pipeline 的status可能取值包括：running、pending、success、failed、canceled、skipped。其中只有前两者是非终态——轮询策略是每 30 秒请求一次，直到没有任何 pipeline 处于running或pending。

7. 定位失败 Job：Pipelines → Jobs

当流水线失败时，需要进一步下钻到具体 Job：

glab api "projects/:fullpath/pipelines/<PIPELINE_ID>/jobs"

每个 Job 对象包含四个关键字段：

• name— Job 名称（如lint、test、build）；
• status— Job 状态；
• stage— 所属阶段（如test、deploy）；
• web_url— 在 Web UI 中查看日志的直达链接。

拿到web_url后即可在评审报告中精确指向失败 Job，便于开发者快速定位日志。

8. 拉取 MR 普通评论与 Bot 评论

除了行内讨论，MR 上还有非 DiffNote 的普通评论（notes端点），其中往往包含 Bot 评审结论：

glab api "projects/:fullpath/merge_requests/<MR_IID>/notes?per_page=100"

按作者过滤即可筛出 Greptile Bot 的评论：

glab api "projects/:fullpath/merge_requests/<MR_IID>/notes?per_page=100" \ | jq '[.[] | select(.author.username == "BOT_USERNAME")]'

需要说明的是：Bot 的确切用户名取决于 Greptile 的安装方式，没有固定值——正确做法是先读取第一条 Greptile 评论，从中识别出它的author.username，再以此作为过滤条件。这与 check-pr 中「先识别 Greptile bot 用户」的流程一致（GitHub 侧对应greptile-apps[bot]）。

9. 向 MR 发布评论：CLI 与 REST 双通道

9.1 CLI 快捷方式

glab mr note <MR_IID> --message "your message here"

9.2 REST API 方式

glab api --method POST \ "projects/:fullpath/merge_requests/<MR_IID>/notes" \ --field body="your message here"

两种方式等价，后者更适合与jq拼接的流水线式脚本（例如把评审摘要直接写入 MR）。注意：glab mr note走的是普通 Note，不会创建行内评论；如需带文件位置的 DiffNote，应使用 discussions 子资源并携带position参数。

10. 在 check-pr 工作流中的完整落位

将上述 API 串起来，就是 check-pr 在 GitLab 平台上的完整执行链路：

1. 探测平台：检查p4 info，否则用git remote get-url origin匹配gitlab关键字（自建 GitLab 域名不含 "gitlab" 时可显式传入--vcs gitlab覆盖）；
2. 识别 MR：glab mr view --output json | jq '.iid'；
3. 等待 CI：轮询 Pipelines 端点 直到全部进入终态；
4. 采集评审数据：Discussions 端点筛未解决 DiffNote + Notes 端点找 Bot 评论 + MR 详情评估描述完整性；
5. 分类与报告：按 Actionable / Informational / Already addressed 分类，输出汇总表；
6. 修复与解决：推送新提交后，对每条未解决讨论逐条执行 PUT resolved=true。

GitHub 侧的对应操作（GraphQL 分页查询、resolveReviewThreadmutation、按updated_at捕捉被原地编辑的 Bot 摘要评论）见配套的 graphql-queries.md；技能的整体安装方式（git clone后对check-pr建立符号链接）见 greptile skills README。本文所列全部命令均可直接复制运行，作为 Agent 或 CI 脚本中 GitLab 评审自动化的可靠依据。

【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer