Fix status checks rendering #4542
Conversation
kabel
commented
Feb 19, 2023
kabel
commented
- Properly converts GraphQL StatusContext and CheckRun types to PullRequestCheckStatus model
- State is mapped from schema defined values to model values
- Avatar URL is converted to enterprise-safe URL (was causing 404s)
- Await the mergable status from GraphQL is it was undefined in the REST list response
- Only set a required review as a failure when there are no other checks or there is review with requested changes
Given
Treeview renderBefore: After: Overview webview with the checks box expanded:Before: and after clicking the description treeview node to "refresh" the model/page: After: |
kabel
force-pushed
the
pr-checks-types
branch
from
3d0f553 to
f394a8c
Compare
|
In f394a8c753909849b766ecf3b7c9f46c5881453a, I included more fixes to better match the web version of the merge message container and tree view. Before After The required reviews message is now pulled out of the checks list and is more accurately shown the right state:
|
* Properly converts GraphQL StatusContext and CheckRun types to PullRequestCheckStatus model * State is mapped from schema defined values to model values * Avatar URL is converted to enterprise-safe URL (was causing 404s) * Await the mergable status from GraphQL is it was undefined in the REST list response * Only set a required review as a failure when there are no other checks or there is review with requested changes
* Uses the GraphQL `refUpdateRule` field to expose branch protection rules * Model `PullRequestReviewRequirement` contains the renderable information Also fixes additional status checks issues * Branch protection expected PR checks are included * Checks include if they are required by branch protection * If the branch is BEHIND, a different merge status is shown * The tree can accurately decorate a PR with review statuses
|
@kabel thank you for all the PRs. I've had a busy March so I haven't had a chance to give them a review yet. We're finishing up our endgame release process now through Monday, and I'm planning to catch up on all the PRs that need my attention starting tomorrow. |
src/github/githubRepository.ts
Outdated
|
|
||
| return [checks, reviewRequirement]; |
There was a problem hiding this comment.
If there are no checks and no rule about requiring reviews we should still return null or undefined. It just going to be noisy for users who don't have rules set up to to see a bunch of green checks so we should just show nothing.
There was a problem hiding this comment.
Sure, I can widen the type of the returned tuple to include null in the first element's type. However, I don't think that will have a martial change on the UI, as the merge component already took into account the lack of (empty array) any status checks.
Edit:
If you meant instead to return null instead of the tuple, that just overly complicates the return handling for the modules that consume this function. As it is now, it will return [null, null] which is a fairly straightforward tuple of two nullable types.
There was a problem hiding this comment.
Example on PR of repo without status checks:
Before
After
