fix(ci): avoid Agentic CI auth comment failure

[andreatgretel]

📋 Summary

This PR prevents successful Agentic CI authorization runs from being marked failed after they already dispatched CI. The failure was caused by gh issue comment using GitHub's GraphQL addComment path, so the workflow now posts PR comments through the REST issue-comments endpoint and treats the final confirmation comment as non-fatal.

🔗 Related Issue

N/A - follow-up to the Agentic CI authorization workflow added in #643.

🔄 Changes

• Replace every gh issue comment call in authorize-agentic-ci.yml with gh api --method POST repos/.../issues/.../comments.
• Add small comment and comment_file helpers for denial comments, including multiline Markdown bodies.
• Make comment-post failures emit workflow warnings instead of masking the intended authorization result.
• Make the final success comment non-fatal after CI and authorization-check dispatches succeed.
• Incorporate Claude review feedback in 2c053acd by hardening failure comments and using a temporary JSON payload for file-backed comment bodies.

🔍 Attention Areas

⚠️ Reviewers: Please pay special attention to the following:

• authorize-agentic-ci.yml - this is the maintainer authorization path for generated Agentic CI PRs, and the comment behavior is intentionally split between fatal authorization failures and non-fatal informational comment failures.

🧪 Testing

• make test passes - N/A, workflow-only change
• Unit tests added/updated - N/A, workflow-only change
• E2E tests added/updated - N/A, issue_comment workflows use the default-branch workflow file and need a post-merge smoke test
• git diff --check
• Parsed .github/workflows/authorize-agentic-ci.yml with PyYAML
• bash -n over each workflow run: block
• /home/ubuntu/Code/repos/DataDesigner/checkouts/main/.venv/bin/ruff check --fix .
• /home/ubuntu/Code/repos/DataDesigner/checkouts/main/.venv/bin/ruff format .
• Created and immediately deleted a temporary REST issue comment on PR fix(ci): avoid Agentic CI auth comment failure #686 using the same gh api endpoint shape
• Claude review completed; non-blocking hardening feedback addressed
• GitHub required checks passing on PR fix(ci): avoid Agentic CI auth comment failure #686

✅ Checklist

• Follows commit message conventions
• Commits are signed off (DCO)
• Architecture docs updated - N/A, workflow-only CI fix

[greptile-apps]

Greptile Summary

This PR migrates all comment-posting calls in authorize-agentic-ci.yml from gh issue comment to the GitHub REST API via gh api --method POST, and makes every comment-posting failure non-fatal (downgraded to a ::warning:: annotation).

• Two shell helpers comment() and comment_file() are introduced in the "Validate Agentic CI PR" step, replacing repetitive inline gh issue comment calls with a consistent gh api pattern.
• The final success comment in the "Dispatch checks" step is now non-fatal, so a transient API error posting the confirmation message no longer causes an otherwise-successful authorization run to fail.

Confidence Score: 5/5

The change is safe to merge — all authorization logic and exit 1 paths are preserved exactly; only the comment-posting mechanism is swapped and downgraded to non-fatal.

Every exit 1 guard remains in place unchanged. The gh api REST call is a direct functional equivalent of gh issue comment, and the comment_file helper correctly builds the JSON payload with jq --rawfile before piping it via --input. Making comment failures non-fatal is an isolated, intentional improvement with no impact on the authorization decision.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/authorize-agentic-ci.yml	Replaces all gh issue comment calls with direct REST API calls via gh api, introduces comment() and comment_file() helper functions, and makes comment-posting failures non-fatal throughout the workflow

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Event (issue_comment)
    participant W as authorize-agentic-ci workflow
    participant API as GitHub REST API

    GH->>W: /authorize-agentic-ci comment

    W->>API: "GET repos/{repo}/collaborators/{author}/permission"
    API-->>W: permission level

    alt permission insufficient
        W->>API: "POST repos/{repo}/issues/{pr}/comments (permission failure)"
        Note over W,API: non-fatal: warning on failure
        W-->>GH: exit 1
    end

    W->>API: "GET repos/{repo}/pulls/{pr} (load metadata)"
    API-->>W: PR JSON (state, head_sha, trusted, etc.)

    W->>API: "GET repos/{repo}/issues/{pr}/timeline (validate comment in timeline)"
    API-->>W: timeline events

    alt validation fails (closed PR / untrusted / missing comment / stale head / blocked files)
        W->>API: "POST repos/{repo}/issues/{pr}/comments (failure reason)"
        Note over W,API: non-fatal: warning on failure
        W-->>GH: exit 1
    end

    W->>API: POST workflow_dispatch (ci.yml)
    W->>API: POST workflow_dispatch (agentic-ci-authorized-checks.yml)
    W->>API: "POST repos/{repo}/issues/{pr}/comments (success confirmation)"
    Note over W,API: non-fatal: warning on failure
    W-->>GH: exit 0

Loading

_{Reviews (2): Last reviewed commit: "fix(ci): harden agentic auth failure com..." | Re-trigger Greptile}

[github-actions]

Review: PR #686 — fix(ci): avoid Agentic CI auth comment failure

Summary

This PR modifies .github/workflows/authorize-agentic-ci.yml to:

1. Replace gh issue comment with gh api --method POST repos/.../issues/.../comments for every comment posted by the workflow.
2. Introduce two local shell helpers (comment and comment_file) inside the "Validate Agentic CI PR" step to DRY the repeated gh api calls.
3. Make the final "authorization succeeded" comment non-fatal — if posting the confirmation comment fails after the dispatch has already happened, the workflow no longer reports authorization as failed; it emits a ::warning:: instead.

Diff is small (+22/-14, single workflow file). PR-only docs change in the workflow itself; no production code, no tests required.

Findings

Correctness

• Equivalence of gh issue comment vs gh api — both endpoints ultimately POST to /repos/:owner/:repo/issues/:number/comments. The -f body=... form-encodes the value, which is the right transport for plain string bodies. The semantic behavior is the same; the swap is reasonable as a workaround for whatever was making gh issue comment fail (the PR description doesn't explain the underlying cause — a sentence on the failure mode would help future readers, but isn't blocking).
• Multi-line body handling via comment_file is correct: jq -n --rawfile body "$1" '{body: $body}' safely produces a JSON object from arbitrary file content (newlines, backticks, quotes), and --input sends it as the request body. Better than relying on shell expansion for multi-line bodies.
• Non-fatal success comment — the final || echo "::warning::..." is the substantive behavioral change. The dispatches (gh workflow run ...) on lines 179–183 happen before the comment, and an unposted confirmation does not invalidate the launched runs, so degrading to a warning is the correct semantics.
• Error-path comments are still fatal — they remain followed by exit 1, which preserves the original semantics: when authorization is denied, the workflow fails. Good asymmetry between success path (best-effort comment) and failure path (must report).
• Stderr visibility — >/dev/null redirects only stdout, so any gh api error output still surfaces in the runner logs for debugging. Correct.

Style / consistency

• Helper duplication across steps. The comment() / comment_file() helpers are defined in the "Validate Agentic CI PR" step, but identical inline gh api ... comments invocations appear in two other steps ("Check commenter permission", line 44–45; "Dispatch checks", line 185–186). Bash functions don't cross step boundaries in GitHub Actions, so duplication here is structurally necessary, but it's worth noting that any future change to the comment idiom (auth header, pagination, error handling) needs to be applied in three places. A future refactor could extract a composite action or a single script file under .github/actions/ if this pattern keeps growing — not blocking for this PR.
• comment_file overwrites the same temp path (/tmp/agentic-ci-auth-comment.json) across both call sites. Calls are sequential within a single step, so no race, but a mktemp would be marginally safer if this helper ever moves into a context with concurrency.
• JSON-encoded vs form-encoded bodies are inconsistent — comment() uses -f body=... (form), comment_file() uses --input <json> (JSON). Both work for this endpoint. Worth a one-line comment in the workflow noting why two paths exist (single-line vs multi-line bodies), since a reader might otherwise wonder.

Security

• Untrusted-content surface unchanged. All bodies posted by these helpers are workflow-controlled strings or files written by the workflow itself (/tmp/agentic-ci-auth-stale.md, /tmp/agentic-ci-auth-failed.md). The BLOCKED shell variable derived from gh pr diff --name-only is interpolated into a markdown bullet list in the failed.md case, but it's escaped only as backtick-wrapped paths — a maliciously named file like `; rm -rf /` would not execute (it's printed inside backticks in markdown, not eval'd), so this remains safe.
• Authorization gating is unchanged. Permission check, trusted-PR check, comment-found check, head-not-changed check, and .github/ blocklist are all preserved. This PR changes only the comment transport and the success-path failure handling, not the security envelope.

Performance / scope

• No measurable runtime change — same number of HTTP calls, same payloads.
• Diff is contained to one workflow file. Within .github/workflows/, which is correctly outside the agentic-CI-modifiable surface.

Suggestions (non-blocking)

1. Consider adding a short comment in the workflow explaining why gh api is used in place of gh issue comment (e.g., "gh issue comment intermittently fails with X — using REST directly avoids that path"). Otherwise a future reader will be tempted to "simplify" it back.
2. If the comment idiom keeps spreading, factor it into a composite action (.github/actions/post-pr-comment) so the three call sites collapse to one definition.
3. mktemp for the JSON staging file in comment_file is a cheap defensive upgrade.

Verdict

Approve with minor optional improvements. The change is small, targeted, and improves robustness of the authorization workflow without weakening its security checks. The non-fatal success comment is the right call — once the dispatches have fired, a comment failure should not retroactively mark the run as a failed authorization. The gh api swap is fine as a transport-level workaround, though the PR would benefit from one sentence explaining the original failure mode it's working around.

[johnnygreco]

Andre, this looks good to me. I reviewed the workflow change for correctness and didn't find any issues; the REST comment path and non-fatal confirmation comment handling both look appropriate.

[johnnygreco]

Looks good to me.