Conversation
kabel
commented
Feb 19, 2023
- 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
3d0f553 to
f394a8c
Compare
* 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. |
alexr00
left a comment
There was a problem hiding this comment.
👏 nice change, thank you! I've made a couple comments, which you can address in the next day or two if you want. Otherwise I plan to approve and merge after I release 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.











