We use green to signify "open" state of issues & PRs in `list` commands
(as opposed to red for "closed" and purple for "merged" state), so let's
be consistent in `status` commands too, where all displayed items are
guaranteed to be open.
This stubs stderr separately from stdout in command tests (before those
streams were combined) and improves test assertions around output.
Additionally, no longer use the `cmd.Print*()` family of Cobra functions
because their name sounds like the text will go to stdout, but they
write to stderr instead. Use the more explicit `cmd.ErrOrStderr()` as
output destination instead.
If a command does `fmt.Print(...)` for output that contains ANSI color
codes, this not safe on Windows. We have to ensure that we always use
the `fmt.Fprint*` family of functions with a writer that was transformed
using `utils.NewColorable()`.
This is for symmetry with `issue list`.
The problem is that the `Repository.pullRequests` connection doesn't
support filtering by assignee, therefore we need to switch to search API
in case an assignee was specified. This is awkward, but I don't see
another way.
When on a `patch-1` branch locally, `gh pr view` would happily open the
first open PR it finds with "patch-1" as its head, even those coming
from forks.
This makes the approach from `pr list` reusable across other commands
that may benefit from table-based output, e.g. `issue list` or `pr status`
The idea is: instantiate a printer, connect it to stdout, feed it some
data, and it does the rest: colored, truncated column output that fits
into a terminal, or tab-delimited output (no color, no truncation) for
scripts.
In a repository that only has a single Check configured (e.g. this
repo), we would print "checks: 1" for PRs where the CI is passing. This
looks akward when repeated for each PR and provides little useful
information.
This avoids ever printing "1" and instead prints "failing", "pending",
or "success", respectively. We now only show numbers for repositories
that have more than one Check runs.
