pony-sync-helper → github_rest_api Gap Analysis

[SeanTAllen]

What pony-sync-helper does

A CLI tool that generates meeting agendas for Pony sync calls. It:

1. Lists all repos in a GitHub org (GET /orgs/{org}/repos, paginated)
2. For each repo, lists issues+PRs with a given label (GET /repos/{owner}/{repo}/issues?labels={label}, paginated)
3. Distinguishes issues from PRs by checking for pull_request field in the JSON
4. Outputs formatted markdown grouped by repo

Currently uses its own HTTP layer (asking/) and hand-rolled JSON parsing.
The goal would be to replace that with github_rest_api.

GitHub API operations pony-sync-helper needs

Operation	Endpoint	Paginated	github_rest_api status
List org repos	GET /orgs/{org}/repos	yes	missing entirely
List repo issues (with label filter)	GET /repos/{owner}/{repo}/issues?labels={label}	yes	missing — only has GetIssue (single issue by number)

What github_rest_api needs to support pony-sync-helper

Must have

1. List organization repositories (paginated)

   • GET /orgs/{org}/repos
   • Returns: PaginatedList[Repository]
   • New primitive: GetOrganizationRepositories or similar
   • Needs only full_name field from the response (Repository model already has this)

2. List repository issues (paginated, with query params)

   • GET /repos/{owner}/{repo}/issues
   • Query params: labels (comma-separated), state (open/closed/all), sort, direction, since, per_page
   • Returns: PaginatedList[Issue]
   • New primitive: GetRepositoryIssues or ListIssues
   • The GitHub issues endpoint returns both issues and PRs — PRs have a pull_request field
   • Issue model needs a way to distinguish issues from PRs (add pull_request field or a boolean)

Nice to have (not strictly required but natural extensions)

3. Query parameter support for list endpoints

   • Currently GetRepositoryLabels hardcodes the URL with no query params
   • List issues needs ?labels=X at minimum
   • Could be as simple as appending query string to URL, or a more structured approach

4. Issue model enhancement

   • Add pull_request field (or at minimum a way to detect PRs in issue listings)
   • Currently the Issue model in github_rest_api doesn't have this field
   • In the GitHub API, the pull_request field is an object with url, html_url, etc. when present, or absent entirely for real issues

Infrastructure that already exists and can be reused

• PaginatedList[A] + PaginatedJsonRequester — handles Link header pagination for top-level array responses. List issues and list org repos both return top-level arrays, so this fits perfectly.
• PaginatedListJsonConverter[A] — converts paginated JSON arrays
• Repository model — already has full_name and dozens of other fields
• Issue model — already has number, title, html_url, labels, state, body
• IssueJsonConverter — already parses issue JSON
• SimpleURITemplate — for URL construction
• Credentials — for auth

Summary

The sync-helper needs two new list operations (org repos + repo issues), both
paginated with top-level array responses. The existing PaginatedList infrastructure
handles this pattern already (same as GetRepositoryLabels). The main work is:

• A new GetOrganizationRepositories primitive (straightforward, follows GetRepositoryLabels pattern)
• A new GetRepositoryIssues primitive (same pattern, plus query parameter support for label filtering)
• Enhancement to the Issue model to include the pull_request field so callers can distinguish issues from PRs

[SeanTAllen]

list organization repositories was added via #52

[SeanTAllen]

list repo issues was added via #57

[SeanTAllen]

query parameters support was added via #59

[SeanTAllen]

issue model enhancement was added via #62