★ FEATURED ARTICLE 人工智能AI 应用语音音频本地部署桌面应用【免费下载链接】auto-subsOn-device subtitle generation that connects directly to DaVinci Resolve, Premiere, and After Effects.项目地址https://gitcode.com/gh_mirrors/au/auto-subs点击查看免费下载本文聚焦 auto-subs 仓库中 Greploop Agent 技能的 GitLab 侧 API 参考文档 gitlab-api.md。Greploop 是一个驱动 AI 代码评审机器人 Greptile 反复评审 PR/MR 直至拿到 5/5 置信度且零未解决评论的循环工作流本文以 GitLabglabCLI GitLab REST API为对象完整讲解如何用glab api获取 MR 详情、轮询 pipeline/job 状态、从 MR notes 中解析置信度分数、抓取并逐条解决 Greptile 的 inline 讨论。读完本文你可以把整套“触发评审 → 轮询完成 → 提取结果 → 修复 → 解决讨论 → 再触发”的闭环命令组合直接落地到自己的 GitLab 项目上。1. 背景greploop 循环与 GitLab API 参考的定位Greploop 技能的完整定义见 SKILL.md其核心是一个有限轮次的迭代循环触发 Greptile 评审GitHub 发greptile review评论、GitLab 发 MR note、Perforce 重新 shelve轮询评审完成状态GitHub 用 check runs、GitLab 用 pipelines/jobs从 MR/PR 描述、评论、review 中解析置信度分数如3/5、5/5修复所有可执行的 inline 评论解决所有已处理的讨论线程提交并推送回到第 1 步。退出条件在 SKILL.md 中写得很明确置信度 5/5 且零未解决评论或达到最多 5 次迭代上限防止失控循环。references/目录为该循环提供了两个平台的 API 参考GitHub 侧是 graphql-queries.mdGraphQL review threads 与批量 resolveGitLab 侧即本文主体 gitlab-api.mdREST glab api。SKILL.md 的 GitLab 轮询伪代码中直接引用了后者原文见 SKILL.md 第 164 行的 “see GitLab API reference”。2. 前提glab api 与 :fullpath 占位符GitLab 侧所有命令都通过glab api发起 REST 请求文档开头给出的关键前提是glab apiautomatically resolves:fullpathto the URL-encoded project path from the local git remote.即glab api会自动从本地 git remote 解析出 URL 编码后的项目路径替换命令中的:fullpath占位符。你不需要手动拼接owner%2Frepo这对以下场景尤其关键自托管 GitLab 实例URL 编码规则可能与实例路径有关仓库路径中包含特殊字符或大小写混用的 group 名命令要在脚本中复用、不硬编码仓库标识的情况。适用前提本地目录是一个已配置origin远端的 git 工作区且glab已完成认证SKILL.md 的 compatibility 声明为 “Requires git, gh (GitHub CLI) or glab (GitLab CLI) authenticated, and Greptile installed on the repo”。另外注意一个平台映射关系SKILL.md 中的 “Key field differences”概念GitHub 字段GitLab 字段MR/PR 内部编号numberiid用这个不是全局id源分支headRefNamesource_branchHEAD 提交headRefOidsha评审触发issue commentgreptile reviewMR notegreptile review评审运行状态check runspipelines jobs通用评论issue commentsMR notesinline 评审线程GraphQL review threadsdiscussionsDiffNote解决线程resolveReviewThreadmutation可批量discussions PUT无批量接口3. 获取 MR 详情第一步永远是定位 MR 本体。文档给出的命令是glab mr view MR_IID --output jsonglab mr view MR_IID --output json需要重点关注的字段原文 Key fields 部分iid— 项目内部的 MR 编号。必须使用它而不是idGitLab 中id是全局唯一的数据库主键而所有merge_requests/MR_IID形式的 REST 路径参数都要求项目内的iidsource_branch— 等价于 GitHub 的headRefName后续git push前可用来确认自己位于正确的分支sha— 该 MR 当前 HEAD 提交的 SHA后面“按提交 SHA 定位 pipeline”一节会用到description— MR 正文。注意Greptile 可能会在每轮评审后回写/更新这个字段例如追加置信度分数块所以每轮循环都要重新拉取而不是缓存。SKILL.md 的实际用法是配合jq快速取两个字段并切分支glab mr view --output json | jq {iid: .iid, branch: .source_branch}4. 触发 Greptile 评审MR noteGitLab 上没有 GitHub check run 那种显式触发接口Greploop 的触发方式是给 MR 发一条 note评论glab mr note MR_IID --message greptile review触发前有一个重要的去重判断先查当前 MR 是否已有 pipeline 在跑避免重复触发完整命令见下一节PIPELINES$(glab api projects/:fullpath/merge_requests/MR_IID/pipelines) GREPTILE_RUNNING$(echo $PIPELINES | jq [.[] | select(.status running or .status pending)] | length) if [ $GREPTILE_RUNNING 0 ]; then glab mr note MR_IID --message greptile review fi这段逻辑来自 SKILL.md 第 147–160 行的 GitLab 分支只有当running/pendingpipeline 计数为0时才发触发评论否则直接进入等待轮询。5. Pipeline 与 Job状态轮询的完整模式5.1 获取 MR 的 pipelinesglab api projects/:fullpath/merge_requests/MR_IID/pipelines返回数组中每个 pipeline 对象有一个status字段文档列出的取值集合为running、pending、success、failed、canceled、skipped。“是否有任何 pipeline 在跑”的判定一行完成glab api projects/:fullpath/merge_requests/MR_IID/pipelines | \ jq [.[] | select(.status running or .status pending)] | length返回0即表示当前没有 running/pending 的 pipeline。注意这里只统计running和pending——success/failed/canceled是终态skipped也不会阻塞新评审因此都不应计入“仍在运行”。5.2 按提交 SHA 定位 pipelineGreptile 的 pipeline 是针对某个 HEAD 提交触发的因此轮询时不能只取“最新 pipeline”而必须按 MR 当前 HEAD SHA 匹配防止拿到上一轮提交的 pipelineglab api projects/:fullpath/merge_requests/MR_IID/pipelines | \ jq -r --arg sha COMMIT_SHA [.[] | select(.sha $sha)] | sort_by(.id) | last | .id // empty这条 jq 值得逐段拆开--arg sha COMMIT_SHA— 通过参数注入 SHA避免把 SHA 直接拼进 jq 程序实际使用时 SHA 来自glab mr view MR_IID --output json | jq -r .sha[.[] | select(.sha $sha)]— 过滤出该 SHA 的 pipeline同一 SHA 理论上可能有多个 pipeline 对象例如重跑场景sort_by(.id) | last— pipeline ID 单调递增取最大 ID 即该 SHA 的最新一次运行.id // empty—关键的防空处理匹配不到时输出空而不是null字符串外层 bash 可以用[ -z $PIPELINE_ID ]判断“pipeline 还没出现继续等”。5.3 获取 pipeline 的 jobs 并锁定 Greptile jobglab api projects/:fullpath/pipelines/PIPELINE_ID/jobs在返回的 jobs 里按name字段与greptile做大小写不敏感匹配文档原文Filter jobs wherenamematchesgreptile(case-insensitive)job 的终态集合是success、failed、canceled。SKILL.md 把它组合成了完整的轮询循环第 166–199 行这就是 Greploop 在 GitLab 上的“等待评审完成”实现HEAD_SHA$(glab mr view MR_IID --output json | jq -r .sha) while true; do PIPELINES$(glab api projects/:fullpath/merge_requests/MR_IID/pipelines) # Find the most recent pipeline for this SHA PIPELINE_ID$(echo $PIPELINES | jq -r --arg sha $HEAD_SHA \ [.[] | select(.sha $sha)] | sort_by(.id) | last | .id // empty) if [ -z $PIPELINE_ID ]; then echo Waiting for Greptile pipeline to appear... sleep 5 continue fi JOBS$(glab api projects/:fullpath/pipelines/$PIPELINE_ID/jobs) GREPTILE_JOB$(echo $JOBS | jq .[] | select(.name | test(greptile; i))) if [ -z $GREPTILE_JOB ]; then echo Waiting for Greptile job to appear... sleep 5 continue fi JOB_STATUS$(echo $GREPTILE_JOB | jq -r .status) if [ $JOB_STATUS success ] || [ $JOB_STATUS failed ] || [ $JOB_STATUS canceled ]; then echo Greptile job completed with: $JOB_STATUS break fi echo Waiting for Greptile... (status: $JOB_STATUS) sleep 10 done这个循环有两个“还没出现”的等待窗口pipeline 对象本身可能尚未由 webhook 创建等 5 秒重试pipeline 存在但 Greptile job 尚未生成再等 5 秒重试job 出现后每 10 秒轮询一次直到终态。对照 GitHub 侧的实现轮询check-runs的status/conclusion可以看到 greploop 的设计模式是统一的“先判存在、再判终态、固定间隔退避”。6. 从 MR notes 中提取 Greptile 置信度分数Greptile 评审完成后分数与总结会以 note评论形式出现在 MR 上。GitLab 侧的获取命令glab api projects/:fullpath/merge_requests/MR_IID/notes?per_page100sortdescorder_bycreated_at三个查询参数的作用per_page100— 单页最多 100 条 notesorder_bycreated_at与sortdesc— 按创建时间倒序最新的评论在前。提取分数时需要两步过滤按作者过滤检查author.username是否是 Greptile bot。文档特别提醒“The Greptile bot username on GitLab may differ from GitHubsgreptile-apps[bot]— check the first Greptile comment on the MR to identify the exact username.”也就是说 GitLab 上的 bot 用户名与 GitHub 侧的greptile-apps[bot]可能不同取决于该实例的 Greptile 安装配置首次运行时必须打开 MR 找到 Greptile 的第一条评论以其中的真实 username 为准之后再把它固化进脚本按正文模式匹配在body中扫描3/5、5/5这类置信度模式SKILL.md 中统一表述为 pattern like3/5or5/5或Confidence: 3/5形式。SKILL.md 在 GitLab 侧还要求同时检查两个来源MR 描述glab mr view MR_IID --output json | jq -r .description和 MR notes因为 Greptile 可能把分数写回 description也可能只在 notes 里留总结。以“最近一次更新”的分数为准。7. 抓取未解决的 inline 讨论discussionsGitLab 把 inline 评审意见组织在discussions讨论串里每个 discussion 包含一组 notes。获取命令glab api projects/:fullpath/merge_requests/MR_IID/discussions?per_page100分页规则文档原文加page2、page3依次请求直到返回数组长度小于per_page为止——这是 GitLab REST API 列表接口的通用分页约定长度等于 100 说明后面可能还有页。从中筛出“Greptile 发的、未解决的 inline diff 评论”的 jq 过滤jq [.[] | select(.resolved false and (.notes[0].type DiffNote) and (.notes[0].author.username GREPTILE_BOT_USERNAME))]三个条件的含义.resolved false— 讨论尚未解决resolved是 discussion 级字段.notes[0].type DiffNote— 首条 note 是 diff 内联评论而非普通 MR note这是 GitLab 区分“评论串是否锚定在 diff 上”的类型标记.notes[0].author.username GREPTILE_BOT_USERNAME— 作者为 Greptile bot占位符替换为第 6 节确定的真实用户名。每个命中的 discussion 对象里Greploop 会用到三个字段文档列出的 “Each discussion has”id— 讨论串 ID解决讨论时作为 URL 参数notes[0].body— 评论正文即要理解与修复的评审意见文本notes[0].position.new_path— 被评论的文件路径用于定位到仓库中的目标文件。SKILL.md 还补充了一个约束这些 DiffNote 应位于最新一次提交上且未解决Filter toDiffNotetype discussions from Greptile that are on the latest commit and not yet resolved避免把历史提交的旧评论误算进本轮修复清单。8. 解决讨论无批量接口的逐条 PUT修复完成后需要把已处理的讨论标记为已解决否则循环的退出条件“零未解决评论”永远不成立。GitLab 的解决接口glab api --method PUT \ projects/:fullpath/merge_requests/MR_IID/discussions/DISCUSSION_ID \ --field resolvedtrue要点方法是PUT不是 POSTresolved通过--field以请求体形式提交DISCUSSION_ID取第 7 节过滤结果里每个 discussion 的idGitLab 没有批量解决接口文档原文GitLab has no batch resolution — issue one PUT per discussion。这一点与 GitHub 形成鲜明对比——GitHub 侧可以一条 GraphQL mutation 里挂t1: resolveReviewThread(...) t2: resolveReviewThread(...)批量解决见 graphql-queries.mdGitLab 侧则必须对每个 discussion 发一次 PUT。脚本化的写法就是一个循环for id in $UNRESOLVED_DISCUSSION_IDS; do glab api --method PUT \ projects/:fullpath/merge_requests/MR_IID/discussions/$id \ --field resolvedtrue done9. 端到端串联gitlab-api.md 在 greploop 循环中的落位把参考文档中的命令按 SKILL.md 的循环步骤A 触发 → 等待 → B 取结果 → C 判退出 → D 修复 → E 解决 → F 提交推送串起来GitLab 侧的完整数据流是glab mr view MR_IID --output json # 取 iid / source_branch / sha / description │ ▼ GET .../merge_requests/MR_IID/pipelines # 有 running/pending │ 无 → glab mr note MR_IID --message greptile review ▼ GET .../merge_requests/MR_IID/pipelines # 按 HEAD_SHA 匹配sort_by(.id)|last ▼ GET .../pipelines/PIPELINE_ID/jobs # test(greptile;i) 锁定 job │ success / failed / canceled → break ▼ GET .../merge_requests/MR_IID/notes?per_page100sortdescorder_bycreated_at │ 过滤 Greptile bot 作者body 中解析 X/5 置信度 ▼ GET .../merge_requests/MR_IID/discussions?per_page100 (pageN 翻页) │ 过滤 resolvedfalse DiffNote Greptile 作者 ▼ 修复每个 DiffNote 指向的新问题 ▼ PUT .../discussions/DISCUSSION_ID --field resolvedtrue # 逐条 ▼ git commit git push → 回到 pipelines 轮询SKILL.md 步骤 F 后回 A退出判定SKILL.md 步骤 C置信度 5/5 且未解决评论为零则结束并输出报告达到 5 次迭代上限则报告当前状态并列出剩余未解决评论。10. 小结与实践提示占位符约定文中MR_IID、PIPELINE_ID、DISCUSSION_ID、COMMIT_SHA、GREPTILE_BOT_USERNAME均为运行时变量:fullpath是glab api原生支持、由本地 remote 自动解析的占位符不要手写成字面量。iid 而非 id所有merge_requests/MR_IID路径参数一律使用 MR 的项目内编号iid。SHA 锚定轮询按 MR 的sha过滤 pipeline 并用sort_by(.id) | last取最新// empty保证“未出现”时轮询能继续等待而不是拿到错误 pipeline。状态枚举要写全pipeline 关注running/pending非终态与success/failed/canceledjob 终态skipped不在运行判定内。bot 用户名要现场确认Greptile 在 GitLab 上的 bot 用户名因安装而异首次运行从 MR 上它的第一条评论里确认再固化到过滤条件中。解决讨论只能逐条 PUT没有批量接口循环发 PUT 是唯一方式这也是 GitLab 与 GitHubGraphQL 批量resolveReviewThread在 API 设计上的实质差异。以上命令与流程均可在 gitlab-api.md 中逐条对照原文循环的整体编排触发去重、轮询节奏、退出条件、报告格式见 SKILL.mdGitHub 侧的 GraphQL 对照实现见 graphql-queries.md。赞分享人工智能AI 应用语音音频本地部署桌面应用【免费下载链接】auto-subsOn-device subtitle generation that connects directly to DaVinci Resolve, Premiere, and After Effects.项目地址https://gitcode.com/gh_mirrors/au/auto-subs点击查看免费下载相关推荐danswer 仓库自动化评审实战基于 glab 的 GitLab MR 讨论与流水线 API 速查danswer 仓库自动化评审实战基于 glab 的 GitLab MR 讨论与流水线 API 速查 在 AI 驱动的代码评审自动化场景中GitLab MeAI 应用大模型RAGAI Agent后端前端以 glab api 驱动 GitLab 审查闭环elsa-core 内置 greploop 技能的 GitLab REST API 实战参考以 glab api 驱动 GitLab 审查闭环elsa core 内置 greploop 技能的 GitLab REST API 实战参考 本篇文章围绕后端工作流自动化流程编排低代码Greploop 实战指南基于 Greptile 自动迭代优化 PR/MR/CL 直至满分评审Greploop 实战指南基于 Greptile 自动迭代优化 PR/MR/CL 直至满分评审 导读 Greploop 是存放在本仓库 .agents/ski后端工作流自动化流程编排低代码上一篇WorkshopDL终极指南无需Steam客户端轻松下载创意工坊模组的开源工具下一篇Docker CLI docker container port 命令详解查询容器端口映射的完整实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
