This commit as a suite of test around different combination of `gh api` field scenarios that result in errors.
In the course of creating this test, there were 2 scenarios that did not raise an error as expected involving overriding an existing map value.
* fix(api): do not interpret "branch" placeholder when `GH_REPO` is set
Before, we would always interpret the "branch" placeholder, typically
setting it to the currently checked-out branch in the repository in the
current working directory. It didn't make sense to do that when the
`GH_REPO` environment variable was specified because the repository
would likely be different from the one in the current working directory.
Now, we instead report an error if both `GH_REPO` environment variable
and `branch` placeholder are specified.
When fetching N pages, avoid printing N separate JSON arrays to the output stream. Instead, massage the output so that the N pages of data are merged into a single JSON array. This is achieved by omitting the final `]` for the first page, and omitting the initial `[` for all subsequent pages.
When connected to a TTY, tell the jq formatter to indent the output, and
enable colorization of the output if the terminal supports it.
Co-authored-by: Mislav Marohnić <mislav@github.com>
This ensures that `IOStreams.Out` always keeps the original `Fd()` value even if it's wrapped as a Colorable stream for Windows in cases when enabling virtual terminal processing has failed.
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]
```
