GitHub status updates

I've tweaked how Reviewable posts commit status updates to GitHub to (hopefully) cause less problems.

It turns out that in some projects Reviewable commit status updates triggered the CI tool, which in turn updated a comment that triggered Reviewable, getting into a vicious cycle that ended only when Reviewable bumped up against the limit of 1000 status updates per commit. Reviewable now no longer temporarily flips the status to pending "Checking status..." and will fall back to an even less invasive approach if it gets close to 1000 checks, so your PR won't get stuck in an error state.

The downside is that if something moves a review from complete back to in-progress, the GitHub status will remain as success for a few extra seconds, opening a small window of opportunity for a merge that maybe shouldn't have been allowed.

Completion conditions and obsolete revisions

In Reviewable, a revision becomes obsolete if any of the commits it covers are no longer part of the PR; this usually happens because of a force push. Those revisions are shown crossed out in the file matrix:

While Reviewable dealt with this just fine, until now custom review completion condition code couldn't tell whether if any of the review's revisions were obsolete. This could lead to unexpected outcomes, especially if you rolled back a branch making the last revision obsolete.

If your completion condition code ever assumed that the last revision is the latest / current one (this includes the sample conditions, if you copied them!), you'll need to fix it like so:

_.last(revisions)                       // BAD OLD WAY
_(revisions).reject('obsolete').last()  // NEW WAY

This goes for both review.revisions and individual file.revisions. I updated the samples so you can safely crib from them again.

BTW, another way to fix this would have been to simply redact obsolete revisions from the data structure passed to the condition code. I decided against this approach because it would preclude some potentially useful condition logic.

Collapsing discussions

Collapsing a long discussion (e.g., by clicking Acknowledge) will no longer scroll you to some seemingly random spot on the page. If the top of the discussion is off-screen, Reviewable will automatically counter-scroll the window so it'll look like the discussion is collapsing from the top down and remain within the viewport.

BTW, the rewrite is making good progress! The end isn't quite in sight yet but it's just over the horizon. :)

Sample commit status in new repos

When you connect a repo, Reviewable will now automatically create a sample commit status (not associated with any PR). This way, you can include Reviewable in the branch protection settings in GitHub even before you've opened your first PR!

This also works nicely in conjunction with the repo auto-connect feature announced a couple days ago.

Automatically connect new repos

If you often create new repos in your organization and forget to connect them to Reviewable — good news! If you're an organization owner, just switch on this toggle on the Repositories page and it'll happen automatically:

Repos should be connected within seconds of being created and will copy the prototype repo's settings as usual. If you manually disconnect a repo it will be opted out of the mechanism forevermore so you can easily make case-by-case exceptions.

You can also automatically connect personal repos but there will be a delay of up to a few minutes after a new one is created since GitHub doesn't send webhooks for this event so Reviewable has to poll instead.

As ever, please let me know if something's broken. :)

More robust logins

If you've ever gotten stuck on a bare "200 OK" page when trying to sign in — particularly in mobile browsers — the issue should be fixed now. I've made the process more robust and implemented a fallback onto a redirect-based method if the popup window approach doesn't complete for any reason.

Copy head branch name

A teeny-tiny new feature while I keep plugging away at the rewrite: there's a small button in the Changes box to copy the PR's head (source) branch name. This can be useful if you want to check out the branch from the repo, and if you do it often there's also a new copyHeadBranch() command for binding a keyboard shortcut.

.gitattributes support

Reviewable now respects the diff settings in your .gitattributes files. For example, to disable diffs for any files in the vendor directory and use PHP higlighting for all .phpt files, you could put a .gitattributes file like this in the root of your repo:

/vendor/** -diff
*.phpt diff=php

For details on the file's syntax please refer to the git docs on the topic.

Designated badge comment author

For those of you who switched badge placement from PR descriptions to comments, you may be glad to know that you can now designate a specific account to create these comments.

This can be useful if you'd rather have a dedicated "bot" account that won't mind getting spammed by notifications from each and every PR.

A quick survey

We're looking over the upcoming priorities for Reviewable and want to know what you think. Please help out by answering an ultra-quick 5 question feedback survey.

No published changelogs yet.

Surely Reviewable will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree