greploop-apps

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Greploop Apps

Greploop Apps

Iteratively fix a PR/MR/CL until Greptile gives a perfect review: 5/5 confidence, zero unresolved comments. This variant tags
@greptile-apps
to trigger reviews, which bypasses the file-count limit that makes Greptile skip huge PRs (e.g. "Too many files changed for review"). Because auto-review skips those PRs, every push needs a fresh
@greptile-apps review
comment.
迭代修复 PR/MR/CL,直到 Greptile 给出完美审查结果:5/5 置信度、零未解决评论。此变体通过标记
@greptile-apps
触发审查,可绕过导致 Greptile 跳过大型 PR 的文件数量限制(例如“Too many files changed for review”)。由于自动审查会跳过这些 PR,每次推送后都需要添加新的
@greptile-apps review
评论。

Inputs

输入

  • PR/MR/CL number (optional): If not provided, detect the PR/MR for the current branch, or the default pending changelist for p4.
  • --max-iterations N
    (optional, default 10): cap on review-fix-push cycles before the loop stops and reports the current state. Raise it for large PRs where Greptile keeps surfacing new findings; lower it to bound cost.
  • PR/MR/CL 编号(可选):如果未提供,则检测当前分支对应的 PR/MR;对于 p4,检测默认的待处理 changelist。
  • --max-iterations N
    (可选,默认 10):限制“审查—修复—推送”循环的次数,达到上限后停止循环并报告当前状态。对于 Greptile 持续发现新问题的大型 PR,可以提高该值;如果希望限制成本,则可以降低该值。

Instructions

指令

0. Detect platform

0. 检测平台

First check for Perforce, then fall back to git remote detection:
bash
undefined
首先检查 Perforce,然后回退到 git remote 检测:
bash
undefined

Check for Perforce environment

Check for Perforce environment

if p4 info >/dev/null 2>&1; then VCS="perforce" else REMOTE_URL=$(git remote get-url origin) if echo "$REMOTE_URL" | grep -qi "gitlab"; then VCS="gitlab" else VCS="github" fi fi

For self-hosted GitLab instances whose hostname doesn't contain "gitlab", the user can override by passing `--vcs gitlab` as an input. For Perforce, pass `--vcs perforce`.
if p4 info >/dev/null 2>&1; then VCS="perforce" else REMOTE_URL=$(git remote get-url origin) if echo "$REMOTE_URL" | grep -qi "gitlab"; then VCS="gitlab" else VCS="github" fi fi

对于主机名不包含“gitlab”的自托管 GitLab 实例,用户可以通过传入 `--vcs gitlab` 作为输入来覆盖检测结果。对于 Perforce,传入 `--vcs perforce`。

1. Identify the PR/MR/CL

1. 确定 PR/MR/CL

GitHub:
bash
gh pr view --json number,headRefName -q '{number: .number, branch: .headRefName}'
GitLab:
bash
glab mr view --output json | jq '{iid: .iid, branch: .source_branch}'
Switch to the PR/MR branch if not already on it.
Perforce:
bash
undefined
GitHub:
bash
gh pr view --json number,headRefName -q '{number: .number, branch: .headRefName}'
GitLab:
bash
glab mr view --output json | jq '{iid: .iid, branch: .source_branch}'
如果尚未切换到 PR/MR 分支,则切换到该分支。
Perforce:
bash
undefined

List pending changelists for current user/client

List pending changelists for current user/client

p4 changes -s pending -u $P4USER -c $P4CLIENT
p4 changes -s pending -u $P4USER -c $P4CLIENT

Describe a specific CL

Describe a specific CL

p4 describe -s <CL_NUMBER>

Ensure the correct workspace (`p4 client`) is set before proceeding.

Key field differences:
- GitHub: `number`, `headRefName`, `headRefOid`
- GitLab: `iid`, `source_branch`, `sha`
- Perforce: changelist number, `P4CLIENT`, shelved files
p4 describe -s <CL_NUMBER>

继续操作前,确保已设置正确的工作区(`p4 client`)。

关键字段差异:
- GitHub:`number`、`headRefName`、`headRefOid`
- GitLab:`iid`、`source_branch`、`sha`
- Perforce:changelist 编号、`P4CLIENT`、已 shelve 的文件

2. Loop

2. 循环

Repeat the following cycle at most
--max-iterations
times (default 10) to avoid runaway loops.
最多重复以下循环
--max-iterations
次(默认 10),以防止失控循环。

A. Trigger Greptile review

A. 触发 Greptile 审查

Push/shelve the latest changes (if any):
GitHub/GitLab:
bash
git push
Perforce:
bash
undefined
推送/shelve 最新更改(如果有):
GitHub/GitLab:
bash
git push
Perforce:
bash
undefined

Re-shelve to update the shelved files for review

Re-shelve to update the shelved files for review

p4 shelve -f -c <CL_NUMBER>

Wait for checks to start after push/shelve:

```bash
sleep 5
GitHub — check if Greptile is already running before posting a new trigger comment:
bash
GREPTILE_STATE=$(gh pr checks <PR_NUMBER> --json name,state | jq -r '.[] | select(.name | test("greptile"; "i")) | .state')
If Greptile is not already running (
PENDING
or
IN_PROGRESS
), request a fresh review:
bash
if [ "$GREPTILE_STATE" != "PENDING" ] && [ "$GREPTILE_STATE" != "IN_PROGRESS" ]; then
  gh pr comment <PR_NUMBER> --body "@greptile-apps review"
fi
Then poll for the Greptile check run to complete:
bash
HEAD_SHA=$(gh pr view <PR_NUMBER> --json headRefOid -q .headRefOid)
ATTEMPTS=0
MAX_ATTEMPTS=60
POLL_INTERVAL_SECONDS=10

while true; do
  ATTEMPTS=$((ATTEMPTS + 1))
  if [ "$ATTEMPTS" -gt "$MAX_ATTEMPTS" ]; then
    echo "Timed out waiting for the Greptile check run after approximately 10 minutes." >&2
    exit 1
  fi

  GREPTILE_CHECK=$(gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs" \
    --jq '.check_runs[] | select(.name | test("greptile"; "i"))' 2>/dev/null)
  
  if [ -z "$GREPTILE_CHECK" ]; then
    echo "Waiting for Greptile check to appear..."
    sleep "$POLL_INTERVAL_SECONDS"
    continue
  fi
  
  STATUS=$(echo "$GREPTILE_CHECK" | jq -r '.status // "completed"')
  CONCLUSION=$(echo "$GREPTILE_CHECK" | jq -r '.conclusion // "pending"')
  
  if [ "$STATUS" = "completed" ]; then
    if [ "$CONCLUSION" = "success" ]; then
      echo "Greptile check passed!"
    else
      echo "Greptile check completed with: $CONCLUSION"
    fi
    break
  fi
  
  echo "Waiting for Greptile... (status: $STATUS)"
  sleep "$POLL_INTERVAL_SECONDS"
done
Huge-PR fallback: on PRs over Greptile's file limit, the tagged review may never create a check run for the new head — Greptile instead edits its existing summary comment when it finishes. If the check run has not appeared after a few attempts, poll the latest Greptile-authored issue comment instead and stop when its
updated_at
moves past the time you posted the trigger and its body carries a confidence score (rather than the "Too many files changed" notice):
bash
gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100" \
  --jq '[.[] | select(.user.login | test("greptile"; "i"))] | sort_by(.updated_at) | last | {updated_at, body}'
If polling times out, stop the greploop workflow and report the timeout. Do not continue with stale or missing review results.
GitLab — check if Greptile is already running before posting a trigger comment:
bash
PIPELINES=$(glab api "projects/:fullpath/merge_requests/<MR_IID>/pipelines")
GREPTILE_RUNNING=$(echo "$PIPELINES" | jq '[.[] | select(.status == "running" or .status == "pending")] | length')
If no pipeline is running, post a trigger comment:
bash
if [ "$GREPTILE_RUNNING" = "0" ]; then
  glab mr note <MR_IID> --message "@greptile-apps review"
fi
Perforce — Perforce does not have native check runs. If Greptile is integrated via a webhook triggered on
p4 shelve
, wait for it to process. Check your Greptile installation's webhook endpoint or dashboard for the review status. Poll by re-fetching the Greptile review comment on the CL until a score appears.
Then poll for the Greptile pipeline job to complete (see GitLab API reference):
bash
HEAD_SHA=$(glab mr view <MR_IID> --output json | jq -r '.sha')
ATTEMPTS=0
MAX_ATTEMPTS=60
POLL_INTERVAL_SECONDS=10

while true; do
  ATTEMPTS=$((ATTEMPTS + 1))
  if [ "$ATTEMPTS" -gt "$MAX_ATTEMPTS" ]; then
    echo "Timed out waiting for the Greptile pipeline job after approximately 10 minutes." >&2
    exit 1
  fi

  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 "$POLL_INTERVAL_SECONDS"
    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 "$POLL_INTERVAL_SECONDS"
    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 "$POLL_INTERVAL_SECONDS"
done
If polling times out, stop the greploop workflow and report the timeout. Do not continue with stale or missing review results.
p4 shelve -f -c <CL_NUMBER>

等待检查在 push/shelve 后启动:

```bash
sleep 5
GitHub——发布新的触发评论前,先检查 Greptile 是否已在运行:
bash
GREPTILE_STATE=$(gh pr checks <PR_NUMBER> --json name,state | jq -r '.[] | select(.name | test("greptile"; "i")) | .state')
如果 Greptile 尚未运行(
PENDING
或
IN_PROGRESS
),则请求一次新的审查:
bash
if [ "$GREPTILE_STATE" != "PENDING" ] && [ "$GREPTILE_STATE" != "IN_PROGRESS" ]; then
  gh pr comment <PR_NUMBER> --body "@greptile-apps review"
fi
然后轮询 Greptile check run,直至完成:
bash
HEAD_SHA=$(gh pr view <PR_NUMBER> --json headRefOid -q .headRefOid)
ATTEMPTS=0
MAX_ATTEMPTS=60
POLL_INTERVAL_SECONDS=10

while true; do
  ATTEMPTS=$((ATTEMPTS + 1))
  if [ "$ATTEMPTS" -gt "$MAX_ATTEMPTS" ]; then
    echo "Timed out waiting for the Greptile check run after approximately 10 minutes." >&2
    exit 1
  fi

  GREPTILE_CHECK=$(gh api "repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs" \
    --jq '.check_runs[] | select(.name | test("greptile"; "i"))' 2>/dev/null)
  
  if [ -z "$GREPTILE_CHECK" ]; then
    echo "Waiting for Greptile check to appear..."
    sleep "$POLL_INTERVAL_SECONDS"
    continue
  fi
  
  STATUS=$(echo "$GREPTILE_CHECK" | jq -r '.status // "completed"')
  CONCLUSION=$(echo "$GREPTILE_CHECK" | jq -r '.conclusion // "pending"')
  
  if [ "$STATUS" = "completed" ]; then
    if [ "$CONCLUSION" = "success" ]; then
      echo "Greptile check passed!"
    else
      echo "Greptile check completed with: $CONCLUSION"
    fi
    break
  fi
  
  echo "Waiting for Greptile... (status: $STATUS)"
  sleep "$POLL_INTERVAL_SECONDS"
done
**大型 PR 回退方案:**对于文件数超过 Greptile 限制的 PR,标记触发的审查可能永远不会针对新 head 创建 check run;Greptile 完成后会改为编辑其现有摘要评论。如果尝试若干次后 check run 仍未出现,则改为轮询最新的 Greptile 作者 issue comment;当其
updated_at
晚于触发评论的发布时间,且正文中包含置信度评分(而不是“Too many files changed”提示)时停止。
bash
gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100" \
  --jq '[.[] | select(.user.login | test("greptile"; "i"))] | sort_by(.updated_at) | last | {updated_at, body}'
如果轮询超时,请停止 greploop 工作流并报告超时情况。不要继续使用过期或缺失的审查结果。
GitLab——发布新的触发评论前,先检查 Greptile 是否已在运行:
bash
PIPELINES=$(glab api "projects/:fullpath/merge_requests/<MR_IID>/pipelines")
GREPTILE_RUNNING=$(echo "$PIPELINES" | jq '[.[] | select(.status == "running" or .status == "pending")] | length')
如果没有任何 pipeline 正在运行,则发布触发评论:
bash
if [ "$GREPTILE_RUNNING" = "0" ]; then
  glab mr note <MR_IID> --message "@greptile-apps review"
fi
Perforce——Perforce 没有原生的 check run。如果 Greptile 通过
p4 shelve
触发的 webhook 集成,则等待其处理完成。检查 Greptile 安装所配置的 webhook 端点或仪表板以查看审查状态。轮询时重新获取 CL 上的 Greptile 审查评论,直到出现评分。
然后轮询 Greptile pipeline job,直至其完成(参见 GitLab API reference):
bash
HEAD_SHA=$(glab mr view <MR_IID> --output json | jq -r '.sha')
ATTEMPTS=0
MAX_ATTEMPTS=60
POLL_INTERVAL_SECONDS=10

while true; do
  ATTEMPTS=$((ATTEMPTS + 1))
  if [ "$ATTEMPTS" -gt "$MAX_ATTEMPTS" ]; then
    echo "Timed out waiting for the Greptile pipeline job after approximately 10 minutes." >&2
    exit 1
  fi

  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 "$POLL_INTERVAL_SECONDS"
    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 "$POLL_INTERVAL_SECONDS"
    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 "$POLL_INTERVAL_SECONDS"
done
如果轮询超时,请停止 greploop 工作流并报告超时情况。不要继续使用过期或缺失的审查结果。

B. Fetch Greptile review results

B. 获取 Greptile 审查结果

Greptile may surface its score in several places — check all of the relevant sources:
GitHub:
1. PR description (body):
bash
gh pr view <PR_NUMBER> --json body -q '.body'
2. General PR comments (issue comments):
bash
gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100"
Filter for Greptile-authored comments and use the body from the most recently updated comment (
updated_at
), not the most recently created comment. Greptile may edit the same general PR comment on each review cycle; parse the current body, including the "Prompt to fix all with AI" section, before deciding there are no remaining issues.
3. PR reviews:
bash
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews
Look for the most recent entry from
greptile-apps[bot]
or
greptile-apps-staging[bot]
.
GitLab:
1. MR description (body):
bash
glab mr view <MR_IID> --output json | jq -r '.description'
2. MR notes (comments):
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/notes"
Filter for notes from the Greptile bot user (check the
author.username
field — the exact username may vary per installation; verify on first run).
Perforce:
1. CL description:
bash
p4 describe -s <CL_NUMBER>
Check the description field for a Greptile-appended score block.
2. CL comments / review notes: If your installation uses a review tool such as Helix Swarm, fetch comments via its API.
Example (Swarm API): GET /api/v11/comments?topic=reviews/<REVIEW_ID>
Response fields of interest typically include:
  • user (author username)
  • body (comment text)
  • flags/state indicating whether the comment is resolved
Filter to comments authored by the Greptile bot:
  • Prefer exact username match if known
  • Otherwise, use a heuristic where the author name contains "greptile" (case-insensitive)
For all platforms, parse the text for:
  • Confidence score: a pattern like
    3/5
    or
    5/5
    (or
    Confidence: 3/5
    ).
  • Comment count: Number of inline review comments noted in the summary.
Use whichever source has the most recently updated score. For GitHub, prefer
updated_at
from issue comments when comparing an edited Greptile summary against older review entries.
Also fetch all unresolved inline comments:
GitHub:
bash
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments
Also carry forward actionable items from the latest Greptile general PR comment, especially the "Prompt to fix all with AI" section, even if the inline comment endpoint returns zero unresolved comments.
GitLab:
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions"
Filter to
DiffNote
type discussions (
notes[0].type == "DiffNote"
) from Greptile that are on the latest commit and not yet resolved (
"resolved": false
).
Perforce: If using Swarm:
Greptile 可能会在多个位置显示评分——请检查所有相关来源:
GitHub:
1. PR 描述(正文):
bash
gh pr view <PR_NUMBER> --json body -q '.body'
2. 普通 PR 评论(issue comments):
bash
gh api --paginate "repos/{owner}/{repo}/issues/<PR_NUMBER>/comments?per_page=100"
筛选 Greptile 撰写的评论,并使用最近更新的评论(
updated_at
)中的正文,而不是最近创建的评论。Greptile 可能会在每个审查周期编辑同一条普通 PR 评论;在判断是否已无剩余问题之前,应解析当前正文,包括“Prompt to fix all with AI”部分。
3. PR reviews:
bash
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews
查找来自
greptile-apps[bot]
或
greptile-apps-staging[bot]
的最新记录。
GitLab:
1. MR 描述(正文):
bash
glab mr view <MR_IID> --output json | jq -r '.description'
2. MR notes(评论):
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/notes"
筛选来自 Greptile bot 用户的 notes(检查
author.username
字段——确切用户名可能因安装而异;首次运行时进行验证)。
Perforce:
1. CL 描述:
bash
p4 describe -s <CL_NUMBER>
检查描述字段中由 Greptile 附加的评分区块。
2. CL 评论/审查备注: 如果安装中使用 Helix Swarm 等审查工具,请通过其 API 获取评论。
Swarm API 示例: GET /api/v11/comments?topic=reviews/<REVIEW_ID>
通常需要关注的响应字段包括:
  • user(作者用户名)
  • body(评论文本)
  • flags/state,用于指示评论是否已解决
筛选 Greptile bot 撰写的评论:
  • 如果已知确切用户名,优先使用精确匹配
  • 否则使用作者名称包含“greptile”的启发式判断(不区分大小写)
对于所有平台,解析以下内容:
  • 置信度评分:类似
    3/5
    或
    5/5
    的模式(或
    Confidence: 3/5
    )。
  • 评论数:摘要中注明的内联审查评论数量。
使用最近更新的评分所对应的来源。对于 GitHub,在比较已编辑的 Greptile 摘要与较旧的审查记录时,优先采用 issue comment 的
updated_at
。
此外,获取所有未解决的内联评论:
GitHub:
bash
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments
还应从最新的 Greptile 普通 PR 评论中继承并处理可执行项,尤其是“Prompt to fix all with AI”部分,即使内联评论端点返回零条未解决评论也不例外。
GitLab:
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions"
筛选来自 Greptile、基于最新 commit 且尚未解决(
"resolved": false
)的
DiffNote
类型 discussions(
notes[0].type == "DiffNote"
)。
Perforce: 如果使用 Swarm:

Fetch inline diff comments for the review associated with the CL

Fetch inline diff comments for the review associated with the CL

GET /api/v11/comments?topic=reviews/<REVIEW_ID>
Filter to comments from the Greptile bot user that have not been marked as resolved/addressed.
GET /api/v11/comments?topic=reviews/<REVIEW_ID>
筛选来自 Greptile bot 用户且尚未标记为已解决/已处理的评论。

C. Check exit conditions

C. 检查退出条件

Stop the loop if any of these are true:
  • Confidence score is 5/5 AND there are zero unresolved comments
  • --max-iterations
    reached (report current state)
满足以下任一条件时停止循环:
  • 置信度评分为 5/5,且未解决评论数量为 0
  • 已达到
    --max-iterations
    (报告当前状态)

D. Fix actionable comments

D. 修复可执行评论

For each unresolved Greptile comment:
  1. Read the file and understand the comment in context.
  2. Determine if it's actionable (code change needed) or informational.
  3. If actionable, make the fix.
  4. If informational or a false positive, note it but still resolve the thread.
对于每条未解决的 Greptile 评论:
  1. 阅读文件并结合上下文理解评论。
  2. 判断它是可执行评论(需要修改代码)还是仅供参考。
  3. 如果可执行,则进行修复。
  4. 如果是信息性评论或误报,请记录下来,但仍要解决该讨论串。

E. Resolve threads

E. 解决讨论串

GitHub — fetch unresolved review threads and resolve all that have been addressed (see GraphQL reference):
bash
gh api graphql -f query='
query($cursor: String) {
  repository(owner: "OWNER", name: "REPO") {
    pullRequest(number: PR_NUMBER) {
      reviewThreads(first: 100, after: $cursor) {
        pageInfo { hasNextPage endCursor }
        nodes {
          id
          isResolved
          comments(first: 1) {
            nodes { body path author { login } }
          }
        }
      }
    }
  }
}'
Resolve addressed threads:
bash
gh api graphql -f query='
mutation {
  t1: resolveReviewThread(input: {threadId: "ID1"}) { thread { isResolved } }
  t2: resolveReviewThread(input: {threadId: "ID2"}) { thread { isResolved } }
}'
GitLab — fetch unresolved discussions and resolve each one (see GitLab API reference):
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100"
Filter for
"resolved": false
discussions. Then resolve each by its
id
:
bash
glab api --method PUT \
  "projects/:fullpath/merge_requests/<MR_IID>/discussions/<DISCUSSION_ID>" \
  --field resolved=true
Repeat for each unresolved discussion ID. (GitLab has no batch resolution — loop through each one.)
GitHub——获取未解决的审查讨论串,并解决所有已处理的讨论串(参见 GraphQL reference):
bash
gh api graphql -f query='
query($cursor: String) {
  repository(owner: "OWNER", name: "REPO") {
    pullRequest(number: PR_NUMBER) {
      reviewThreads(first: 100, after: $cursor) {
        pageInfo { hasNextPage endCursor }
        nodes {
          id
          isResolved
          comments(first: 1) {
            nodes { body path author { login } }
          }
        }
      }
    }
  }
}'
解决已处理的讨论串:
bash
gh api graphql -f query='
mutation {
  t1: resolveReviewThread(input: {threadId: "ID1"}) { thread { isResolved } }
  t2: resolveReviewThread(input: {threadId: "ID2"}) { thread { isResolved } }
}'
GitLab——获取未解决的 discussions,并逐一解决(参见 GitLab API reference):
bash
glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100"
筛选
"resolved": false
的 discussions,然后根据其
id
逐一解决:
bash
glab api --method PUT \
  "projects/:fullpath/merge_requests/<MR_IID>/discussions/<DISCUSSION_ID>" \
  --field resolved=true
对每个未解决的 discussion ID 重复上述操作。(GitLab 不支持批量解决——请逐个循环处理。)

F. Commit and push / re-shelve

F. 提交并推送/重新 shelve

GitHub/GitLab:
bash
git add -A
git commit -m "address greptile review feedback (greploop iteration N)"
git push
Perforce:
bash
undefined
GitHub/GitLab:
bash
git add -A
git commit -m "address greptile review feedback (greploop iteration N)"
git push
Perforce:
bash
undefined

Stage changes back into the CL and re-shelve for the next review round

Stage changes back into the CL and re-shelve for the next review round

p4 shelve -f -c <CL_NUMBER>

Wait for checks to start after push/shelve:

```bash
sleep 5
Then go back to step A.
p4 shelve -f -c <CL_NUMBER>

等待检查在 push/shelve 后启动:

```bash
sleep 5
然后返回步骤 A。

3. Report

3. 报告

After exiting the loop, summarize:
FieldValue
PlatformGitHub / GitLab / Perforce
IterationsN
Final confidenceX/5
Comments resolvedN
Remaining commentsN (if any)
If the loop exited due to max iterations, list any remaining unresolved comments and suggest next steps.
退出循环后,汇总:
字段值
平台GitHub / GitLab / Perforce
迭代次数N
最终置信度X/5
已解决评论N
剩余评论N(如有)
如果循环因达到最大迭代次数而退出,请列出所有剩余的未解决评论并建议后续操作。

Output format

输出格式

Greploop complete.
  Platform:      GitHub
  Iterations:    2
  Confidence:    5/5
  Resolved:      7 comments
  Remaining:     0
If not fully resolved (
<N>
is the effective cap — the
--max-iterations
value supplied, or 10 by default):
Greploop stopped after <N> iterations (--max-iterations <N>).
  Platform:      GitLab
  Confidence:    4/5
  Resolved:      12 comments
  Remaining:     2

Remaining issues:
  - src/auth.ts:45 — "Consider rate limiting this endpoint"
  - src/db.ts:112 — "Missing index on user_id column"
Perforce example:
Greploop complete.
  Platform:      Perforce
  Changelist:    12345
  Iterations:    3
  Confidence:    5/5
  Resolved:      9 comments
  Remaining:     0
Greploop complete.
  Platform:      GitHub
  Iterations:    2
  Confidence:    5/5
  Resolved:      7 comments
  Remaining:     0
如果未完全解决(
<N>
为实际生效的上限,即传入的
--max-iterations
值,默认为 10):
Greploop stopped after <N> iterations (--max-iterations <N>).
  Platform:      GitLab
  Confidence:    4/5
  Resolved:      12 comments
  Remaining:     2

Remaining issues:
  - src/auth.ts:45 — "Consider rate limiting this endpoint"
  - src/db.ts:112 — "Missing index on user_id column"
Perforce 示例:
Greploop complete.
  Platform:      Perforce
  Changelist:    12345
  Iterations:    3
  Confidence:    5/5
  Resolved:      9 comments
  Remaining:     0