If a GitHub repo is configured to automatically delete branches after PR
is merged, `gh pr merge` fails with error like:
failed to delete remote branch: ... (422): 'Reference does not exist'
Gracefully handle such case and don't report the error.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
`fmt.Errorf` hides information and makes it hard to test for specific
conditions in returned error. Return a structured error instead.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
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.
