Given the GraphQL query:
issues(filterBy: {assignee: $assignee})
It turns out that passing a query variable `"assignee": null` is NOT
equivalent to omitting the variable altogether:
- `"assignee": null` seems to filter out issues that HAVE an assignee;
- omitting `assignee` correctly returns all issues.
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.
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.
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.
