While a gh command is writing stdout to a pager, the user may choose to
close the pager program before the pager has read all the data on its
standard input. In that case, the parent gh process will receive an
EPIPE error, which would bubble up its error handling and cause it to
print something like:
write |1: broken pipe
Since this was caused by an explicit user action of closing the pager,
and since the user probably doesn't want to see this uninformative
error, this informs our global error handling of this error and causes
it to be ignored.
Add pager functionality to the following commands:
- gist list
- pr checks
- release list
- run list
- run view
- secret list
- workflow list
- workflow view
Additionally, normalize error handling when starting the pager has
failed: only print a non-fatal notice to stderr instead of aborting the
whole command.
- This fixes issue 5061.
- Previously, a user could set `GH_REPO=TestOrg/repo` and run `gh api
repos/{owner}/{repo}/releases` expecting to see the releases from
`TestOrg/repo` but instead see releases from the current git repo
they're in.
- Or, worse, if the user ran the command from outside of a git repo,
they'd see a "not a git repo" error from git itself.
- This was different to `GH_REPO=TestOrg/repo gh release list` which
successfully lists `TestOrg/repo`'s releases.
----
Before:
```shell
$ cd repos/issyl0/not-a-git-repo
$ GH_REPO=issyl0/terraform-provider-improvmx gh api repos/{owner}/{repo}/releases
unable to expand placeholder in path: fatal: not a git repository (or any of the parent directories): .git
/opt/homebrew/bin/git: exit status 128
```
```shell
$ cd repos/issyl0/a-git-repo-with-no-releases
$ GH_REPO=issyl0/terraform-provider-improvmx gh api repos/{owner}/{repo}/releases
[]
```
After:
```shell
$ cd repos/issyl0/not-a-git-repo
$ GH_REPO=issyl0/terraform-provider-improvmx ../../cli/cli/bin/gh api repos/{owner}/{repo}/releases
[lots of JSON about GH_REPO's releases - success]
```
```shell
$ cd repos/issyl0/a-git-repo-with-no-releases
$ GH_REPO=issyl0/terraform-provider-improvmx ../../cli/cli/bin/gh api repos/{owner}/{repo}/releases
[lots of JSON about GH_REPO's releases - success]
```
Whenever a SSO challenge gets issued by the server by means of a URL in
the `X-GitHub-SSO` response header, gh now additionally prints that URL
on the standard error stream.
This is achieved by installing a middleware to all HTTP requests and
storing the server challenge to a value accessible by `factory.SSOURL()`.
Such approach was made necessary mainly because of the
`shurcool-graphql` client which doesn't give access to response headers
when a GraphQL error case is encountered.
If a 4xx server response lists scopes in the X-Accepted-Oauth-Scopes
header that are not present in the X-Oauth-Scopes header, the final
error messaging on stderr will now include a hint for the user that they
might need to request the additional scope:
$ gh codespace list
error getting codespaces: HTTP 403: Must have admin rights to Repository. (https://api.github.com/user/codespaces?per_page=30)
This API operation needs the "codespace" scope. To request it, run: gh auth refresh -h github.com -s codespace
m[2] is the third element of m, rather than the second, so we have to
check instead that the len of m is at least 3.
Because the regular expression has two capture groups, the length of m
will always be 3, so currently the guard will always be true.
Proposing a slight amendment to the `gh api` field docs to clarify the current limitation around "complex" field values, e.g. arrays/objects.
Related: #1484
Signed-off-by: Michael Gasch <mgasch@vmware.com>
With the `--format` flag, the value of the flag is parsed as a Go
template which is then evaluated against parsed response data.
https://golang.org/pkg/text/template
