GitHub review attempts
REVIEW below is the absolute path to scripts/github_review.py inside the
installed greploop skill. Run it from the target repository with authenticated
gh. Both trigger names use this same implementation.
Start and wait
After pushing, use a new artifact path for each cycle:
python3 "$REVIEW" start --repo OWNER/REPO --pr 123 \
--trigger @greptile --output .artifacts/greploop/attempt-1.json
python3 "$REVIEW" wait .artifacts/greploop/attempt-1.json \
--timeout 600 --interval 10start posts a PR comment. Use it only when the task authorizes the review
loop. Pass --trigger @greptile-apps for the alternate route. The helper
snapshots checks, comments, and reviews before posting and records the trigger's
server timestamp and current head. It refuses to overwrite an attempt file.
If start fails before posting, it removes the attempt file, so you can reuse the
same path. If it fails after posting, inspect the PR and saved state before
retrying; use wait on a confirmed attempt instead of posting again.
If a Greptile check is already running, start refuses to post another trigger;
let that run finish, then rerun start. After --stuck-after seconds, 1800 by
default, start treats a running check as stuck and posts anyway. A check with
no start time never ages out. If you confirm it is stuck, pass the
--ignore-check ID named in the error.
wait is read-only. It paginates all result sources, verifies the head before
and after reading, and rejects old completed checks and unchanged summaries.
A scored review must be newer than the trigger. A PR review carries its own
commit_id; an issue summary must carry its own last-reviewed-commit link.
A separate review cannot establish a markerless summary's revision or score.
A fresh scored PR review can supply its own result. This also permits
large-PR reviews that update a summary without creating a check run.
A fresh running check keeps the attempt pending. A cancelled, skipped, stale,
or timed-out check stops it. On the default trigger, a fresh "Too many files
changed" notice with no fresh scored review also stops it; start a new attempt
with --trigger @greptile-apps.
The alternate route keeps waiting through that notice, because an automatic
review can post it before the requested review finishes. Review findings can accompany a failed check, so
read the score and body instead of equating check success with code correctness.
The helper's review_ready result means fresh feedback is available; it does
not certify that the PR is ready to merge.
The default trusted logins are greptile-apps[bot] and
greptile-apps-staging[bot]. For another installation, verify its identity and
pass repeatable --bot EXACT_LOGIN arguments to start.
If a provider omits revision metadata, report that freshness could not be
verified. Do not substitute the PR description or an arbitrary 5/5 string.
Inspect and resolve findings
Read the returned body and all general-comment findings. Then use the
GraphQL reference to fetch unresolved threads. Follow
pageInfo.endCursor until hasNextPage is false. Identify Greptile by its exact
trusted author login. GraphQL may omit the [bot] suffix shown by REST;
verify the bot's GraphQL identity before filtering threads. Read full thread discussions before deciding a finding
is addressed; the initial query only returns a few comments per thread.
Use isResolved on review threads for resolution state. The REST inline
comments endpoint does not provide that state. Keep unresolved older threads
in the review, even if their original commit differs from the current head.
After checking and publishing fixes, resolve only the addressed thread IDs.
Fetch again to confirm the final unresolved count and verify the head still
matches the reviewed revision before reporting success.
API fields: check runs, PR reviews.