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
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
- Clarify that fields need to be in "key=value" format
- Headers need to be in "key:value" format
- Contrast POST vs GET requests with params in examples
- Add an example of how to add HTTP headers
- Use backticks where applicable
Accept the "HOST/OWNER/REPO" syntax or passing a full URL for both the
`--repo` flag and the GH_REPO environment variable and allow setting
GH_HOST environment variable to override just the hostname for
operations that assume "github.com" by default.
Examples:
$ gh repo clone example.org/owner/repo
$ GH_HOST=example.org gh repo clone repo
$ GH_HOST=example.org gh api user
$ GH_HOST=example.org gh gist create myfile.txt
$ gh issue list -R example.org/owner/repo
$ gh issue list -R https://example.org/owner/repo.git
$ GH_REPO=example.org/owner/repo gh issue list
