When applying metadata to the new PR such as assignees or reviewers, if
the operation fails, an error message would get printed:
failed to create pull request: <API error text>
This was misleading, because the PR did get created; it's just that
updating it failed. The new error message is:
https://github.com/OWNER/REPO/pull/123
pull request update failed: <API error text>
The PR URL is printed on stdout and the error message is printed on
stderr. In case of any errors, the exit code is still non-zero.
We install an HTTP middleware that adds the "Authorization" header on
every HTTP request. However, our asset download process might redirect
to a 3rd-party host (Amazon S3) and we want to allow those requests but
not require that they are authenticated.
Furthermore, we need the ability to specify the `Accept` request header
without it being overwritten by middleware, so now middleware only adds
headers that are not present in a request.
Ensure the response body is fully read and closed to reuse the same TCPconnection.
Co-authored-by: Kumar Saurabh <kumarsaurabh@Kumars-MacBook-Air.local>
Any errors from fetching and rendering the README were silenced and
ignored in `repo view`. This change:
- Tolerates HTTP 404, but will raise exceptions for any other error;
- Moves markdown rendering from `api` package to command implementation;
- Ensures markdown rendering errors are correctly reported.
First, consolidate the functionality between `pr merge` and `pr
checkout` that resolves the default branch name of the base repo. With
an added bonus, the new approach avoids an API request when one isn't
necessary.
Then, ensure that checking out 3rd-party PRs will result in local branch
name such as `<owner>/<branch>` when the head branch of the repository
matches the default branch of the base repository. We already have had
code in place to take care of this, but it only took effect in the `pr
checkout <number>`-style invocation.
