If `gh release create <TAG>` was called and TAG exists locally but not on the remote, this warns about the unpushed tag to avoid recreating it on the remote. The user can pass a value for `--target` to silence the warning.
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.
After completing the interactive `gh auth login` flow, the `hosts.yml`
config file will have been populated with both `oauth_token` and `user`
properties for the GitHub host. However, after `auth login --with-token`
only the `oauth_token` is persisted but no username.
This fixes `auth git-credential` behavior so it allows authentication
even if the `user` property is missing. It's entirely optional to send a
proper username for git authentication, since GitHub seems to ignore the
actual value sent and just focuses on the token itself.
* pr-checks: extract webMode
* pr-checks: extract checks information collection
* pr-checks: extract output utilities
* pr-checks: implement watch flag
* pr-checks: remove SIGINT interceptor
* pr-checks: exit with error if some task has failed
* update flags help text
* update default interval to 10s
* move interval flag parse to RunE
* refactor checksRunWatchMode to use infinite loop
* Refactor printTable function
* Refactor collect function
* Set up checksRun to use new refactored functions and simplify logic a bit
* Add tests
* Always set interval in opts
* use Duration flag
* Revert back to using int flag for consistency with run watch
* Use run watch screen clearing mechanism
* Re-add pager support
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
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.
* feat: add job id, into run view suggest command
* fix: dry
* fix: run id to job id
* Change "a" to "the" when referencing a single job
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
* Add branch and actor filters to `run list`
* Simplify what FilterOptions can do
* Check not only limit in TestNewCmdList
* Verify that branch/actor params are parsed properly
* Verify that API requests have proper query parameters
* Change flag name from actor to user
Co-authored-by: Sam Coe <samcoe@users.noreply.github.com>
If the base branch has no minimum approval requirements, show "N Approved"
reviews. Otherwise, show "N/X Approved".
Co-authored-by: Mislav Marohnić <mislav@github.com>
- 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.
