This commit is part of work to make gh more scriptable. It includes both
some general purpose helpers towards this goal as well as improvements
to the issue commands. Other commands will follow.
- Adds `utils/terminal.go` for finding out about gh's execution environment
- introduces `stubTerminal` for either faking being attached to a tty or not during tests
- updates issue commands to behave better when not attached to a tty:
- issue list doesn't print fuzzy dates
- issue list doesn't print header
- issue list prints state explicitly
- issue create no longer hangs
- issue create fails with clear error unless both -t and -b are specified
- issue view prints raw issue body
- issue view prints metadata in a consistent, linewise format
- Code should be intented per Markdown syntax for a code block. This
matters when this documentation is rendered to HTML
- Fix some innaccurate usage examples
- Tweak wording, formatting in a few places
When `{owner}` and `{repo}` strings are found in request path (for REST
requests) or `query` (for GraphQL), they are replaced with values from
the repository of the current working directory.
Previously we would trigger OAuth flow when the config file did not
exist. Now we will let an empty Config object be initialized in that
case, but trigger OAuth flow when the Context caller requests an
AuthToken.
When executing `gh pr re` (note the incomplete command name), Cobra
would just display the help text for `gh pr` on standard output, exit
with status 0, and not print any message that you have mistyped the
"re" subcommand. Each part of this behavior is wrong.
This workaround makes sure that the helpful error message is printed on
stderr:
$ gh pr re
unknown command "re" for "gh pr"
Did you mean this?
reopen
ready
review
However, the exit status is still 0, whereas it should be non-zero.
Since `HelpFunc` does not return an error argument, we cannot trigger an
error status from this workaround.
Our code had an unspoken assumption that only one apiClient is created
during the course of a command. Violating this assumption is fine in
almost all cases, but not when we need to do a re-auth to add a new
oauth scope to a user's token.
There is likely a more elegant solution to the problem but until then
this changes determineBaseRepo to use an existing apiClient.
