Skip to content

ci: sync Antigravity reviewer to the fixed comment-selection version #341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
doublegate merged 1 commit into from
Aug 3, 2026
+242 −31
Merged

ci: sync Antigravity reviewer to the fixed comment-selection version #341

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 135 additions & 0 deletions scripts/agy-review-selftest.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
#!/usr/bin/env bash
#
# agy-review-selftest.sh -- guards the comment-selection logic in `agy-review.sh`.
#
# Why this exists: that filter decides which PR comments the bot DELETES, and it has been wrong
# twice, both times invisibly.
#
# 1. The just-posted comment was not reliably excluded. `new_comment_id` came from re-querying
# the comment list, which races GitHub's read replication; on a miss the exclusion became
# `select(.id != null)`, true for every id, and the run deleted the review it had just
# published.
# 2. jq's `--arg`/`--argjson` were handed to `gh api`, which has no such flags. It exited
# non-zero, `2>/dev/null` hid the message, and `set -o pipefail` + `set -e` killed the script
# AFTER posting — so stale comments silently accumulated and the job went red with nothing in
# the log explaining why.
#
# Neither was catchable by looking at the review the bot posted: both times it posted fine. So the
# filter is tested here directly, offline, against fixtures — no network, no `gh`, no runner.
#
# Run: bash scripts/agy-review-selftest.sh

set -euo pipefail

SCRIPT_DIR="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)"

# Source the constants out of the reviewer without running it. `agy-review.sh` does its work at
# top level, so it cannot simply be sourced; the two values under test are lifted by pattern
# instead. That coupling is deliberate: if either declaration is renamed or reshaped, this test
# fails loudly rather than silently checking a stale copy of the filter.
extract_marker() {
sed -n 's/^MARKER="\(.*\)"$/\1/p' "$SCRIPT_DIR/agy-review.sh" | head -n 1
}
extract_filter() {
sed -n "/^SELECT_STALE_JQ='/,/'\$/p" "$SCRIPT_DIR/agy-review.sh" \
| sed "1s/^SELECT_STALE_JQ='//; \$s/'\$//"
}

MARKER="$(extract_marker)"
FILTER="$(extract_filter)"

[ -n "$MARKER" ] || { echo "FAIL: could not extract MARKER from agy-review.sh" >&2; exit 1; }
[ -n "$FILTER" ] || { echo "FAIL: could not extract SELECT_STALE_JQ from agy-review.sh" >&2; exit 1; }

# A non-empty extraction is not the same as a COMPLETE one. The `sed` range above ends at the
# first line closing with a quote, so a filter whose body ever ends a line that way would be
# truncated — and a truncated jq program can still be valid and still return ids, which is the
# silent-wrong-answer this whole file exists to prevent. Two independent guards:
#
# 1. it must compile (a truncated program is usually, though not always, a syntax error);
# 2. it must END with the projection, which is what makes it a complete pipeline rather than a
# prefix of one.
# The named args must be supplied here too: the filter references `$marker`/`$new_id`, and jq
# rejects an undefined variable at COMPILE time — so omitting them fails a perfectly good program.
if ! printf '[]' | jq --arg marker x --argjson new_id 0 "$FILTER" >/dev/null 2>&1; then
echo "FAIL: extracted SELECT_STALE_JQ is not a valid jq program (truncated?):" >&2
printf '%s\n' "$FILTER" >&2
exit 1
fi
case "$(printf '%s' "$FILTER" | tr -d '[:space:]')" in
*'|.id') : ;;
*) echo "FAIL: extracted SELECT_STALE_JQ does not end in '| .id'; extraction truncated" >&2
printf '%s\n' "$FILTER" >&2
exit 1 ;;
esac

fixture() {
cat <<JSON
[
{"id": 111, "user": {"type": "Bot", "login": "github-actions[bot]"}, "body": "$MARKER\nold review"},
{"id": 222, "user": {"type": "Bot", "login": "github-actions[bot]"}, "body": "$MARKER\nolder still"},
{"id": 333, "user": {"type": "User", "login": "someone"}, "body": "$MARKER\nnot ours"},
{"id": 444, "user": {"type": "Bot", "login": "other-bot"}, "body": "$MARKER\nwrong bot"},
{"id": 555, "user": {"type": "Bot", "login": "github-actions[bot]"}, "body": "an ordinary bot comment"},
{"id": 999, "user": {"type": "Bot", "login": "github-actions[bot]"}, "body": "$MARKER\nJUST POSTED"}
]
JSON
}

# Ids as a single space-separated line, with no trailing space — so the expected values below read
# as what they are rather than carrying padding an assertion would have to mirror.
select_ids() {
fixture | jq -r --arg marker "$MARKER" --argjson new_id "$1" "$FILTER" | sort -n | paste -sd' ' -
}

fails=0
check() {
local name="$1" want="$2" got="$3"
if [ "$got" = "$want" ]; then
echo " ok $name"
else
echo " FAIL $name"
echo " want: [$want]"
echo " got: [$got]"
fails=$((fails + 1))
fi
}

echo "agy-review comment-selection self-test"

# The whole point: the comment just published is never selected for deletion.
check "excludes the just-posted comment" "111 222" "$(select_ids 999)"

# The author filter is a security control, not tidiness: without it any user could paste the
# marker into a comment and have the bot delete comments on the next run.
check "ignores other users and other bots" "111 222" "$(select_ids 999)"

# A bot comment without the marker is somebody else's feature (a CI summary, a deploy note).
check "ignores bot comments without the marker" "111 222" "$(select_ids 999)"

# Regression #1, pinned: an unknown id must not select everything. The caller now refuses to run
# the delete at all in this case, but the filter itself is checked so the two guards are
# independent rather than one relying on the other.
check "an id of 0 still excludes nothing real" "111 222 999" "$(select_ids 0)"

# A different id in the set behaves the same way, so the exclusion is genuinely by value.
check "excludes whichever id it is given" "222 999" "$(select_ids 111)"

# Regression #2, pinned: `--arg`/`--argjson` belong to jq. If they are ever moved onto `gh api`
# again, that command exits non-zero — assert the flags are not passed to `gh api` in the script.
# Line continuations are folded first: `--arg` moved onto a continuation line would otherwise sit
# on a different physical line from `gh api`, and a line-by-line grep would report a false pass on
# exactly the mistake this check exists to catch.
if sed -e ':a' -e '/\\$/{N;s/\\\n//;ba' -e '}' "$SCRIPT_DIR/agy-review.sh" \
| grep -qE 'gh api[^|]*--(arg|argjson)'; then
echo " FAIL --arg/--argjson passed to \`gh api\` (jq flags; gh api rejects them)"
fails=$((fails + 1))
else
echo " ok --arg/--argjson are not passed to \`gh api\`"
fi

if [ "$fails" -ne 0 ]; then
echo "$fails check(s) failed" >&2
exit 1
fi
echo "all checks passed"
138 changes: 107 additions & 31 deletions scripts/agy-review.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -100,6 +100,22 @@ AGY_RETRIES="${AGY_RETRIES:-3}" # attempts to get a usable agy respon
AGY_RETRY_DELAY="${AGY_RETRY_DELAY:-15}" # base backoff seconds between retries (grows per attempt)
MARKER="<!-- antigravity-pr-review -->"

# The jq program that picks which prior review comments to delete. Named, and exercised directly
# by `scripts/agy-review-selftest.sh`, because this filter has now been wrong TWICE in ways
# nothing observed: first the just-posted comment was not excluded (so it deleted itself), then
# jq's `--arg` was handed to `gh api`, which has no such flag (so the whole step died silently and
# stale comments accumulated). Both were invisible from the outside — the review still posted.
#
# The two `select`s that matter: the AUTHOR filter (without it, any user could put the marker in a
# comment and have this bot delete arbitrary comments) and the ID exclusion (without it, the run
# deletes the comment it just published).
SELECT_STALE_JQ='.[]
| select(.user.type == "Bot" and .user.login == "github-actions[bot]")
| select(.body | contains($marker))
| select(.id != $new_id)
| .id'
readonly SELECT_STALE_JQ

REPO="${GITHUB_REPOSITORY:?GITHUB_REPOSITORY not set}"

# --- resolve the PR number from the triggering event --------------------------
Expand Down Expand Up @@ -411,16 +427,30 @@ here="$(cd "$(dirname "$0")" && pwd)"
# Serialize agy across concurrent review jobs on this host. agy runs a SINGLETON
# local language-server + conversation store per user, so two `--print` calls at
# once collide (one reports the backend "unavailable"). flock makes jobs queue
# instead of failing. Best-effort: if the lock can't be taken, proceed anyway.
if command -v flock >/dev/null 2>&1; then
# Create the lock dir first: a failed `exec 9>` redirection is a FATAL shell error (it aborts
# before the `|| log` fallback can run), so ensure the parent exists on a fresh runner. `>>` opens
# for append rather than truncating the lockfile — flock uses the fd, not the contents.
mkdir -p "$(dirname "$AGY_LOCK")" 2>/dev/null || true
exec 9>>"$AGY_LOCK" 2>/dev/null \
&& flock -w "$AGY_LOCK_WAIT" 9 \
|| log "agy lock unavailable or timed out (${AGY_LOCK_WAIT}s); proceeding unserialized"
# instead of failing. FAIL CLOSED: if flock is missing, or the lock can't be
# taken/times out, exit rather than let two agy processes race each other --
# a fail-open here made the exact collision this lock exists to prevent still
# reachable (one run can burn the whole ${AGY_RETRIES}x${AGY_LOCK_WAIT}s wait).
command -v flock >/dev/null 2>&1 || {
log "flock is required to serialize agy; refusing to run unserialized"
exit 1
}
# Create the lock dir first: a failed `exec 9>` redirection is a FATAL shell error (it aborts
# before the `|| log` fallback can run), so ensure the parent exists on a fresh runner. `>>` opens
# for append rather than truncating the lockfile — flock uses the fd, not the contents.
# Validated before use: an empty `AGY_LOCK` (an env override set to "") would make `dirname`
# yield "." and the redirection below fail with an obscure shell error, at the one point where a
# clear message matters -- this is the guard that keeps two agy runs off each other.
if [ -z "$AGY_LOCK" ]; then
log "AGY_LOCK is empty; refusing to run unserialized"
exit 1
fi
mkdir -p "$(dirname "$AGY_LOCK")"
exec 9>>"$AGY_LOCK"
flock -w "$AGY_LOCK_WAIT" 9 || {
log "agy lock timed out after ${AGY_LOCK_WAIT}s"
exit 1
}

# Retry the whole agy attempt on empty/failed output: transient "agy is down"
# (backend rate-limit / local-server contention) usually clears within seconds.
Expand Down Expand Up @@ -512,31 +542,77 @@ body_file="$(mktemp)"
printf '\n\n<sub>Automated first-pass review by `agy` on a self-hosted runner -- not a human review.</sub>\n'
} > "$body_file"

# --- replace any prior review comment, then post fresh -------------------------
# A failed delete is logged, not swallowed: silently ignoring it would let a transient API/perms
# error leave the old comment in place AND post a new one, so runs accumulate duplicates.
# The author filter is load-bearing, not cosmetic: without it, ANY user could put the
# marker (an HTML comment) in a PR comment and have this bot delete arbitrary comments on
# the next run. Only ever delete OUR OWN bot's prior review comments.
gh api "repos/${REPO}/issues/${PR}/comments" --paginate \
--jq ".[] | select(.user.type == \"Bot\" and .user.login == \"github-actions[bot]\") | select(.body | contains(\"${MARKER}\")) | .id" 2>/dev/null \
| while read -r cid; do
[ -n "$cid" ] || continue
if ! gh api -X DELETE "repos/${REPO}/issues/comments/${cid}" >/dev/null 2>&1; then
log "warning: could not delete prior review comment ${cid}; a duplicate may result"
fi
done

# Final hard guard — the last line of defense, and UNCONDITIONAL. Layer 1 (the retry loop)
# already rejects a lapsed-session capture, but a public PR comment must NEVER carry a live
# OAuth authorization URL, whatever any upstream change does to the body — and with no "looks
# like a review" exemption that a header alongside a URL could disarm. A genuine review that
# merely discusses auth or quotes this script's bare regex has no live URL and posts normally;
# only an actual authorization URL blocks the post.
# Final hard guard — the last line of defense, and UNCONDITIONAL, run BEFORE anything is
# deleted or posted. Layer 1 (the retry loop) already rejects a lapsed-session capture, but
# a public PR comment must NEVER carry a live OAuth authorization URL, whatever any upstream
# change does to the body — and with no "looks like a review" exemption that a header
# alongside a URL could disarm. A genuine review that merely discusses auth or quotes this
# script's bare regex has no live URL and posts normally; only an actual authorization URL
# blocks the post.
if oauth_url_present "$body_file"; then
log "refusing to post: the assembled comment body contains a live OAuth authorization URL. Re-authenticate agy on the runner host."
exit 1
fi

gh pr comment "$PR" --repo "$REPO" --body-file "$body_file"
# --- post fresh, THEN replace any prior review comment --------------------------
# Publish-before-delete, deliberately: if this ordering were reversed and posting failed
# afterward (a transient gh/API error), the PR would be left with NO review comment at all
# instead of the still-valid prior one. Posting first means a failure here can only ever
# leave a harmless duplicate, never a silent loss of the last review.
# The posted comment's id comes from the POST itself, not from a read-back. `gh pr comment`
# prints the new comment's URL, whose trailing `#issuecomment-<id>` is authoritative the instant
# it returns. Re-querying the comment list to find "the newest one with our marker" raced with
# GitHub's own read replication: right after posting, the list can still omit it, and then the
# exclusion below matched nothing and the script deleted the comment it had just published --
# turning publish-before-delete into publish-then-destroy, the exact failure the ordering exists
# to prevent.
if ! post_output="$(gh pr comment "$PR" --repo "$REPO" --body-file "$body_file" 2>&1)"; then
# Nothing is deleted when the post fails: the prior review comment is still the best
# information the PR has, and removing it would leave no review at all.
log "failed to post review to ${REPO}#${PR}: ${post_output}"
exit 1
fi
log "posted review to ${REPO}#${PR}"
new_comment_id="$(printf '%s\n' "$post_output" | sed -n 's/.*#issuecomment-\([0-9][0-9]*\).*/\1/p' | tail -n 1)"

# A failed delete is logged, not swallowed: silently ignoring it would let a transient API/perms
# error leave the old comment in place alongside the new one, so runs accumulate duplicates.
# The author filter is load-bearing, not cosmetic: without it, ANY user could put the
# marker (an HTML comment) in a PR comment and have this bot delete arbitrary comments on
# the next run. Only ever delete OUR OWN bot's prior review comments -- and only ones from
# BEFORE this run (the just-posted comment's own id is excluded so it can never delete itself).
if [ -z "$new_comment_id" ]; then
# FAIL CLOSED. Without a known id there is no way to tell the new comment from the old ones,
# and the safe direction is unambiguous: a leftover duplicate is noise, deleting the review
# that was just posted is data loss.
log "warning: could not determine the posted comment id; leaving prior review comments in place"
else
# `--arg`/`--argjson` rather than shell interpolation into the filter: the marker is an HTML
# comment today, but a quote or a backslash in it would otherwise break the jq program itself
# rather than simply not matching.
#
# Those are JQ flags, so the JSON is fetched raw and piped into a real `jq` — `gh api` has no
# `--arg`/`--argjson` of its own and rejects them. Handing them to `gh api --jq` made it exit
# non-zero on every run; with the old `2>/dev/null` swallowing the message and `set -o pipefail`
# in force, the script then died *after* posting, so the stale comments were never deleted and
# the job went red for a reason nothing printed. stderr is kept this time for exactly that
# reason. (`--paginate` without `--jq` emits one JSON array per page; `jq` reads that stream
# fine, applying `.[]` to each.)
stale_ids="$(
gh api "repos/${REPO}/issues/${PR}/comments" --paginate \
| jq -r --arg marker "$MARKER" --argjson new_id "$new_comment_id" "$SELECT_STALE_JQ"
)" || {
log "warning: could not list prior review comments; leaving them in place"
stale_ids=""
}
while read -r cid; do
[ -n "$cid" ] || continue
if ! gh api -X DELETE "repos/${REPO}/issues/comments/${cid}" >/dev/null 2>&1; then
log "warning: could not delete prior review comment ${cid}; a duplicate may result"
fi
done <<< "$stale_ids"
fi

# The delete loop above is the last real work; end on a defined status so a stray non-zero from
# it can never be mistaken for "the review failed" once the comment is already published.
exit 0
Comment on lines +557 to +618

@coderabbitai coderabbitai Bot Aug 3, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Does the gh CLI gh pr comment command print the created comment's URL to stdout on success, and is this documented/stable behavior?

💡 Result:

The gh pr comment command in the GitHub CLI does not print the created comment's URL to stdout upon success [1][2]. The command is designed for interaction with the GitHub PR system, and its standard behavior is to perform the requested action (posting the comment) without returning the URL or other machine-readable metadata about the created resource to standard output [1][2]. Because this behavior is not documented as a feature of the command, it is not considered a stable or supported way to retrieve the comment URL [1]. Users who need the URL or further details about the created comment should instead use the gh api command, which allows for direct interaction with the GitHub REST API and can return the full JSON response containing the resource URL [2][3]. For example, to obtain the comment URL or ID, you can use the REST API endpoint for creating a comment via gh api [2][4]: gh api --method POST /repos/{owner}/{repo}/issues/{issue_number}/comments -f body="your comment body" This approach provides a stable, machine-readable output that includes the full details of the created resource [2][3].

Citations:

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- script references ---'
rg -n -C 4 'gh pr comment|new_comment_id|gh version|GH_PAGER|gh-cli|github-cli' scripts .github 2>/dev/null || true
printf '%s\n' '--- workflow/action files ---'
git ls-files '.github/*' 'scripts/agy-review.sh' | sed -n '1,160p'

Repository: doublegate/RustyNES

Length of output: 6944

🌐 Web query:

site:cli.github.com/manual/gh_pr_comment gh pr comment output URL stdout

💡 Result:

The gh pr comment command does not explicitly output the URL of the created comment to standard output (stdout) [1]. The official documentation for gh pr comment lists options for specifying the body of the comment, such as using --body or --body-file, but it does not document an option to return the URL of the resulting comment upon successful execution [1]. Because this information is not provided by the command's standard output, it is not possible to capture the comment URL directly from the command execution in the manner requested [1].

Citations:

🌐 Web query:

site:github.com/cli/cli "pr comment" "issuecomment-" output

💡 Result:

The term "issuecomment-" refers to the prefix used in GitHub's REST and GraphQL APIs to identify individual comments on issues or pull requests [1][2]. In the context of GitHub Actions and the GitHub CLI (gh), this prefix is used when referencing specific comments for operations like updates or deletions [2][3]. Key points regarding "issuecomment-" and GitHub operations: 1. Identification: GitHub identifies comments using a unique numeric ID [1]. When interacting with the API or using tools that interface with it, these IDs are often prefixed with "issuecomment-" (e.g., issuecomment-123456789) to explicitly denote the object type [2]. 2. Usage in GitHub CLI: While the GitHub CLI (gh) provides high-level commands like gh pr comment --edit-last to simplify common tasks [4][2], it does not natively provide a direct command like gh comment update that takes an "issuecomment-" ID as a primary argument [1][2]. Instead, users often interact with these IDs via the GitHub API directly using gh api [2] or by piping JSON output from commands like gh issue view --json comments into tools like jq [1][3]. 3. PR vs. Issue Comments: In GitHub's data model, a pull request is a type of issue, meaning that comments on pull requests are technically issue comments [5][6]. This is why the same API endpoint (/repos/{owner}/{repo}/issues/comments/{comment_id}) is used to manage comments for both issues and pull requests [1]. 4. Automation and Permissions: When attempting to post or manage comments within a GitHub Actions workflow, ensure your job has the appropriate permissions (typically pull-requests: write or issues: write) [7][6]. If you encounter errors, verify that you are using the correct secret (secrets.GITHUB_TOKEN) and that the workflow event (e.g., pull_request vs. pull_request_target) provides the necessary access to the repository [6]. If you are trying to automate the updating or deletion of a comment, the recommended pattern is to retrieve the list of comments via the GitHub CLI in JSON format, use jq to filter for the specific comment ID, and then call the REST API via gh api [2][3].

Citations:

🏁 Script executed:

#!/bin/bash
set -eu
python3 - <<'PY'
import json, urllib.request
urls = [
    "https://raw.githubusercontent.com/cli/cli/trunk/pkg/cmd/pr/comment/comment.go",
    "https://raw.githubusercontent.com/cli/cli/master/pkg/cmd/pr/comment/comment.go",
]
for url in urls:
    try:
        data = urllib.request.urlopen(url, timeout=10).read().decode()
    except Exception as exc:
        print(f"{url}: {exc}")
        continue
    print(f"--- {url} ---")
    for i, line in enumerate(data.splitlines(), 1):
        if "URL" in line or "url" in line or "Fprintln" in line or "Println" in line:
            print(f"{i}:{line}")
PY

Repository: doublegate/RustyNES

Length of output: 586

🌐 Web query:

GitHub CLI source pkg/cmd/pr/comment/comment.go prints comment URL Fprintln

💡 Result:

In the GitHub CLI (gh) source code, the logic for adding a comment to a pull request is not entirely contained within pkg/cmd/pr/comment/comment.go, which serves primarily as the command definition [1]. Instead, the operational logic—including the printing of the resulting comment URL—is largely delegated to shared functionality found in pkg/cmd/pr/shared/commentable.go [2]. Specifically, when a comment is successfully created via the GitHub API, the commentable.go file uses fmt.Fprintln to output the URL of the new comment to the standard output stream (unless the quiet flag is set) [2]. The relevant code block typically looks like this: if!opts.Quiet { fmt.Fprintln(opts.IO.Out, url) } This behavior ensures that after executing gh pr comment, the user is provided with a direct link to the created resource [3][2]. Other formatting and printing of existing comments (e.g., when viewing them) are handled separately in files such as pkg/cmd/pr/shared/comments.go, which also utilize fmt.Fprintln to format and display comment bodies and their associated metadata in the terminal [4].

Citations:

🏁 Script executed:

#!/bin/bash
set -eu
for url in \
  https://raw.githubusercontent.com/cli/cli/trunk/pkg/cmd/pr/shared/commentable.go \
  https://raw.githubusercontent.com/cli/cli/trunk/pkg/cmd/pr/comment/comment.go
do
  echo "--- $url ---"
  curl -ksSfL "$url" | nl -ba | grep -E -C 5 'Fprintln|Quiet|url|comment' | head -n 100
done

Repository: doublegate/RustyNES

Length of output: 530

🌐 Web query:

site:cli.github.com/manual/gh_pr_comment "URL" "standard output"

💡 Result:

There is no technical concept known as URL standard output. The phrase appears to be a misunderstanding or a conflation of terms. The WHATWG URL Standard defines how URLs are parsed and serialized [1], but it does not define an output format under that specific name. In command-line interface tools, such as the GitHub CLI, standard output is a common concept where commands return information to the terminal or allow data to be piped from a file [1].

Citations:

🌐 Web query:

site:cli.github.com/manual/gh_pr_comment "quiet" "comment"

💡 Result:

No results were found for:

site:cli.github.com/manual/gh_pr_comment "quiet" "comment"

The GitHub CLI manual page may not contain a quiet option for gh pr comment.

🏁 Script executed:

#!/bin/bash
set -eu
python3 - <<'PY'
import ssl, urllib.request
ctx = ssl._create_unverified_context()
urls = [
    "https://raw.githubusercontent.com/cli/cli/trunk/pkg/cmd/pr/shared/commentable.go",
    "https://raw.githubusercontent.com/cli/cli/trunk/pkg/cmd/pr/comment/comment.go",
    "https://cli.github.com/manual/gh_pr_comment",
]
for url in urls:
    print(f"--- {url} ---")
    try:
        text = urllib.request.urlopen(url, context=ctx, timeout=15).read().decode("utf-8", "replace")
    except Exception as exc:
        print(exc)
        continue
    lines = text.splitlines()
    for i, line in enumerate(lines, 1):
        if any(term in line for term in ("Fprintln", "Quiet", "quiet", "URL", "url", "body-file")):
            lo, hi = max(1, i - 4), min(len(lines), i + 4)
            for j in range(lo, hi + 1):
                print(f"{j}:{lines[j-1]}")
            print()
PY

Repository: doublegate/RustyNES

Length of output: 8849

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- workflow setup and gh invocations ---'
rg -n -C 5 'setup.*gh|install.*gh|gh version|gh pr comment|apt.*gh|brew.*gh|cli/cli' .github scripts README.md 2>/dev/null || true

Repository: doublegate/RustyNES

Length of output: 23612

🌐 Web query:

GitHub CLI gh pr comment manual created comment URL printed stdout

💡 Result:

The GitHub CLI gh pr comment command does not natively print the URL of the created comment to standard output (stdout) [1][2]. The command primarily functions to add a comment and provides user feedback (if any) via standard error (stderr) or the terminal display when run interactively, rather than returning the new comment's URL as machine-readable output. If you need to obtain the URL of a newly created comment within a script, you can use the gh api command instead of gh pr comment. By using the GitHub REST API, you can capture the JSON response, which contains the html_url of the comment [3][4]. Example approach using gh api: # Example script to create a comment and capture its URL comment_url=$(gh api \ --method POST \ -H "Accept: application/vnd.github+json" \ /repos/:owner/:repo/issues/:number/comments \ -f body="Your comment text here" \ --jq.html_url) echo "Comment created at: $comment_url" This method gives you direct access to the created comment's URL, which you can then store or process as needed [5].

Citations:

Pin gh or use a machine-readable comment response

The current gh pr comment implementation prints the created URL when --quiet is absent, and this invocation does not use --quiet. However, the manual does not document this stdout contract, and the workflow does not pin a gh version. Pin the CLI version and test the output, or create the comment with gh api and parse its JSON id.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@scripts/agy-review.sh` around lines 557 - 618, Replace the `gh pr comment`
publication in the review-posting flow with `gh api` creating the issue comment,
and parse the response JSON `id` directly into `new_comment_id`. Preserve the
existing post-failure handling and stale-comment deletion logic, using the API
response as the authoritative identifier instead of parsing undocumented CLI
output.