[CLEAN] Synthetic Benchmark PR #36313 - FEATURE: GitHub PR live status icon #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Benchmark PR discourse#36313
Type: Clean (correct implementation)
Original PR Title: FEATURE: GitHub PR live status icon
Original PR Description: I wanted a better way to show a live/up-to-date status of a PR than what the https://github.com/discourse/github-status-theme provided.
First, I wanted it to work on any PR, including ones in private repositories.
Second, I wanted to include the approved status, which requires a 2nd call to GitHub's API.
Third, I wanted something that was less "intrusive" than the "shield-like" status, so I opted out to use the icons & color that GitHub uses (but maybe that's a bad idea).
So here's what I came up with. It's basically a small initializer script that hooks into the "decorate" APIs for posts and chat messages, and sends a requests to retrieve the PR status for each GitHub pull request oneboxes.
The server-side proxy is there to add the GitHub token (via the github_onebox_access_tokens site setting) to access private repositories as well as doing some post-processing to retrieve the approved status.
There is no caching, neither client-side, nor server-side, as I wanted to see how it felt in production and how often we would hit any rate limits.
BEFORE
AFTER
Internal ref - t/17138
Original PR URL: discourse#36313