Fixes `panic: unsupported status: ""`
This occurs when a CheckRun has status "IN_PROGRESS" (or any other than
"COMPLETED") and when its `conclusion` would be null. I previously
didn't account for this.
This adds support for parsing state of an in-progress CheckRun.
This was a typo. Note that Makefile is only used for building a
development version after cloning from git; the tagged release process
uses `.goreleaser.yml` and skips the Makefile.
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.
Before, we've used the `reviews` connection to iterate through all
reviews chronologically and try to guess the final state of reviews.
This approach had several problems:
- it didn't handle dismissed reviews well,
- the conclusion would likely be wrong if the number of total reviews
exceeded the per-page limit.
The `pe_mobile` feature flag exposes the `reviewDecision` field that
handles all of this for us.
With the old approach, we had to enumerate all StatusContexts and
CheckRuns to calculate whether a PR has passing or failing CI status.
Using `statusCheckRollup` which is behind the `pe_mobile` feature flag,
this is somewhat simpler because both StatusContexts and CheckRuns are
now behind the same connection.
Additionally, should we decide to *not* show the number of
passing/failing checks, this now approach allows us to consume the
`statusCheckRollup { state }` field and avoid paginated collections
and calculating the "winning" state altogether.
