Skip to content

feat(cli,sdk): add pull request comments and reviews#3009

Open
aeonbilal wants to merge 1 commit into
block:mainfrom
aeonbilal:feat/cli-pr-comment
Open

feat(cli,sdk): add pull request comments and reviews#3009
aeonbilal wants to merge 1 commit into
block:mainfrom
aeonbilal:feat/cli-pr-comment

Conversation

@aeonbilal

Copy link
Copy Markdown

Summary

  • buzz pr comment for plain and inline PR comments, with --body / --body-file and repeatable --to
  • buzz pr review --decision approve|request-changes for review decisions; the body falls back to a short summary if you don't pass one
  • build_git_pr_comment in the SDK, publishing the same kind:1 shape Desktop does: root e tag, repo a tag, deduped p tags, plus the review facets
  • SDK event-shape tests, and the CLI inventory tests updated

Why

The CLI could open and manage PRs but couldn't take part in reviewing one. social publish --reply-to isn't a substitute: it emits an e tag and nothing else, and project clients fetch conversation with kinds:[1] plus #a:[<repoAddress>], so a note without the repo coordinate never reaches a reader.

Fixes #3008

Notes

  • Anchor paths are validated, not normalized, same rule as the Desktop anchor validator. Absolute paths, . and .. segments, empty segments, backslashes and NULs are rejected.
  • Inline comments and review decisions both require --commit, so a reader knows which revision the comment applies to. If a decision is also anchored, c is emitted once.
  • Who may review is still a client-side convention, since the relay doesn't enforce it. The builder only checks event shape and doesn't try to reimplement canReviewProjectPullRequest.
  • No overlap with feat(cli): add project issue comments #3001, and it follows the same builder pattern.

Verification

  • cargo test -p buzz-sdk -p buzz-cli — 492 passed, 0 failed
  • cargo clippy -p buzz-sdk -p buzz-cli --all-targets -- -D warnings — clean
  • cargo fmt --check -p buzz-sdk -p buzz-cli — clean
  • by hand: buzz pr comment --help / buzz pr review --help, and both an inline comment without --commit and a comment with no body get rejected at parse time

Desktop can comment on and review project pull requests, but the CLI
could not: `buzz pr` was open/update/get/list/status only. The obvious
workaround does not work either — `social publish --reply-to` emits an
`e` tag alone, while project clients fetch conversation with a relay
filter of `kinds:[1]` plus `#a:[<repoAddress>]`, so a note without the
repository coordinate is never returned to any reader.

Add `build_git_pr_comment` to the SDK and `buzz pr comment` /
`buzz pr review` to the CLI, emitting the same event shape Desktop
publishes: a root `e` tag, the repository `a` tag, deduplicated `p`
recipients, and the review facets — `inline-comment` with `c`/`file`/
`side`/`line` for diff anchors, `approval` or `changes-requested` for
decisions. Anchor paths are validated, never normalized, mirroring the
Desktop validator so no client is asked to trust a rewritten path.

Review eligibility remains a client-side convention in Buzz — the relay
does not enforce who may approve — so the builder validates event shape
only.
@aeonbilal
aeonbilal requested a review from a team as a code owner July 26, 2026 17:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI cannot comment on or review Projects pull requests: no buzz pr comment / buzz pr review

1 participant