The login name of the authenticated user will be readily available only
if authentication info comes from the config file. With other upcoming
authentication modes (for example, the GITHUB_TOKEN environment
variable), the token is the only piece of information we got, so we
would need to additionally query for the login name.
Since `issue status` and `pr status` are the only commands that need the
name of the authenticated user right now, have those commands explicitly
query for the login name. This results in an additional API query, but
simplifies Context implementation and future authentication approaches.
Our code had an unspoken assumption that only one apiClient is created
during the course of a command. Violating this assumption is fine in
almost all cases, but not when we need to do a re-auth to add a new
oauth scope to a user's token.
There is likely a more elegant solution to the problem but until then
this changes determineBaseRepo to use an existing apiClient.
When reviewers were requested on a PR, they would apparently
overwrite the current set of reviewers. A fresh PR will already have
reviewers if it was assigned some by CODEOWNERS rules.
The fix is to only ever add additional reviewers and not overwrite the
entire set.
At the time we have a reference to `baseRepo`, we might still not have
contacted the API nor obtained any information about the default branch
for the repository. This expands the `PullRequests()` query to always
report the default branch so we may choose how to render entries that
belong on the current branch.
this commit add very basic non-interactive PR reviewing. You can either
review the "current" or a passed PR (number or URL) as approved, changes
requested, or commented via CLI flags.
