Refined-github: Favicon coloring based on PR status

[raghavrv]

Hi,

I think it would be nice to have coloring in the github icon based on the PR status.

Example:

Use case: Sometimes I leave some PRs that I review unclosed to revisit them later after CIs pass (or fail). It would be nice to quickly check that without going into the tab.

For instance this is being done in CI status pages like travis, appveyor et all...

[sindresorhus]

I like how Travis does this.

[hkdobrev]

Could this include whether PR is mergeable? So not only CI status, but also whether there's an approval if it was required?

[raghavrv]

We could add a star next to the icon to denote non-merge-ability maybe... But I'd recommend against coloring based on mergeability...

To me this coloring would tell me if I need to visit the page or wait for the CIs to turn green... Reviews on the other hand don't typically involve a fixed wait time where this could be useful...

But it would be nice to know that too without visiting the page... So a star or a specific separate symbol for that would be good...

[paulmolluzzo]

I don't see the value in just showing if CIs passed. Those are automated and usually only take a short period of time to run. More to the point, if CIs pass and something else blocks merging (e.g. Conflicts or review denial), showing a green icon because my linter passed is, at best, inaccurate.

If we add a star for merging, what about other automated runners? I have sites with a deployment preview that can pass/fail. Test coverage can drop, the repo owner can request changes, etc. Should each of these get a special symbol?

I say keep it simple: Green is everything passed, red is something failed, yellow is something has a warning or needs specific input (i.e. Merge conflict, someone asked for changes to be made to the PR).

My 2¢.

[hkdobrev]

👍 to what @paulmolluzzo said, but then I thought of a good (but complex) solution (I think).

What if we use what GitHub uses to show some reviewers have approved and others have requested changes - a multi-coloured green/red pie.

So here's my concrete suggestion:

If PR doesn't require an approval and there's only one commit status:
We have 3 icons - green, yellow, red - representing the commit status

If PR doesn't require approval and there are multiple commit statuses:
We may either use the 3 icons - green, yellow, red to indicate the total status or we can use a combination - half in green + half in red, half in yellow + half in green etc. If there are two commit statuses - every half represent one, if there are more than two - we could just one half in green if there's something passed and the other half in red if anything has not passed, otherwise yellow.

If PR requires an approval and there aren't commit statuses:

• Green if all who were requested has approved and there aren't any requested changes
• Red if there are only change requests
• Yellow if there are no reviews yet
• Green + Red if there are both approvals and change requests
• Green + Yellow if there's an approval, but someone who was requested hasn't reviewed yet
• Green + Red if there are both approvals and change requests
• Red + Yellow if there's a change request, but someone who was requested hasn't reviewed yet

If PR requires an approval and there are commit statuses:

• First half is for reviews, second half is for commit statuses
• Green if everything's OK, Red if something has failed, Yellow if something hasn't finished yet

---

I guess this is a bit too much, but we could probably simplify it if you think the direction is right - combining colours in the icon.

[raghavrv]

Those are automated and usually only take a short period of time to run.

Completely depends on your CI... I constantly work with CIs (that are used only for testing rather than deployment) that are super congested and take 30 minutes to even start running and another 15 mins to complete at best... Even that could be considered short when you compare with some CIs that take several hours to start/pass...

what about other automated runners? I have sites with a deployment preview that can pass/fail. Test coverage can drop

One can add a status check for each of those...

To clarify I'm saying let's make the favicon colored same as that of the "github status check", but not the review status alone...

This

But not this

I agree, * is a poor suggestion...

[raghavrv]

Half in green half in red is a neat idea... Thanks @hkdobrev...

[paulmolluzzo]

@hkdobrev's idea is interesting, but it's pretty complex. I'd need a cheat sheet to remember all these scenarios, and worse they'll change from repo to repo depending on third party processes. To top it all off the icon is... 32px square?

Further, this extension becomes kind of "transparent" over time. (@raghavrv forgot he had it installed! :smile:) Even if you commit this to memory you might forget, and then you have to remember if it's from GH officially or not and hunt down documentation... IDK.

Completely depends on your CI... I constantly work with CIs (that are used only for testing rather than deployment) that are super congested and take 30 minutes to even start running and another 15 mins to complete at best... Even that could be considered short when you compare with some CIs that take several hours to start/pass...

My point was super general and reductive, you're right. But this could be a yellow icon and still meet your specific needs, be expressive enough to show temporary state in other scenarios, and simple enough to grok without documentation/memorization.

Green: All good.
Yellow: Waiting on something.
Red: Fails for a reason.

[raghavrv]

@raghavrv forgot he had it installed!

:P

How about color it like @paulmolluzzo suggests and add a status mark (green tick / red x / grey x / yellow dot) next to it just before the title?*

*Looks like the favicons can't be rectangular to do that, so how about a unicode mark ✔ / ✘ / ⚫

EDIT: Favicons if you need them - https://gist.github.com/raghavrv/1a1f5de88eab754c1298ba4448a862d7 (click on view raw)

[sindresorhus]

We should try to keep it simple.

---

I won't get much benefit from it anyways. This is how my browser looks... 😫

[raghavrv]

okay this gives the state of the PR :

document.getElementsByClassName('statuses-toggle-opened')[0].parentNode.parentNode.getElementsByClassName('status-heading')[0].innerHTML.trim()...

EDIT: Using jquery - all_statuses = $('.statuses-toggle-opened').parents(2).find('.branch-action').find('.status-heading').map(function(i, e) {return e.innerHTML.trim()})

I can try and make a PR... Any guidance on where to fiddle? I have not touched javascript in a long while...

So keeping it absolutely simple, we want -

Green: All good.
Yellow: Waiting on something.
Red: Fails for a reason
Black: If PR not open / Issue

[paulmolluzzo]

EDIT: Using jquery - all_statuses = $('.statuses-toggle-opened').parents(2).find('.branch-action').find('.status-heading').map(function(i, e) {return e.innerHTML.trim()})

I think you'll want to look for something closer to $('.branch-action-item .completeness-indicator') - this is the actual icon, and if it's a success it has the class .completeness-indicator-success as well. The Changes Requested item is an svg with a class on a path.

I can try and make a PR... Any guidance on where to fiddle? I have not touched javascript in a long while...

You might want to put this in a separate file and then you'll include and use it on on PR pages in content.js, probably in this block:

if (pageDetect.isPR()) {
   linkifyBranchRefs();
   addDeleteForkLink();
}

NB: I'm still not sure how all the cases would pan out. What would you show for something like this PR? https://github.com/sindresorhus/refined-github/pull/346 We will have to account for a lot of different scenarios and have some logic that reduces the possibilities to 3 or 4 options.

[raghavrv]

Sorry for the late response...

For #346, I guess red as we decided (Fails on something (something=merge conflict))?

[raghavrv]

You might want to put this in a separate file and then you'll include and use it on on PR pages in content.js, probably in this block:

Thanks... I'll try to make a PR tomorrow!

[paulmolluzzo]

For #346, I guess red as we decided (Fails on something (something=merge conflict))?

@raghavrv I guess that makes sense. It clearly can't just be merged as is.

Thanks... I'll try to make a PR tomorrow!

Awesome!

[fregante]

GitHub got to it first. Less work for us!

[MarcusNoble]

I'd like to re-open this issue if possible. While GitHub has implemented this feature it doesn't cover all cases. The favicon indicators only relate to the CI checks and not if it's been approved by reviewers. So the green tick can show but the PR still not in a state where it can be merged. I'd love it if refined-github could tweak this so that the yellow dot is shown until all the checks are showing green.