Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 17 14:50
    pkaminski labeled #654
  • Jan 17 14:36
    pkaminski closed #790
  • Jan 17 07:46
    pkaminski closed #781
  • Jan 17 03:28
    Server build 2686 deployed
  • Jan 17 03:19
    pkaminski closed #788
  • Jan 17 03:19
    pkaminski commented #788
  • Jan 17 03:19
    Client build 4471 deployed
  • Jan 16 01:31
    jwnimmer-tri commented #753
  • Jan 14 06:11
    Client build 4453 deployed
  • Jan 14 05:58
    pkaminski edited #482
  • Jan 14 05:58
    pkaminski commented #482
  • Jan 13 03:37
    pkaminski commented #782
  • Jan 13 03:28
    pkaminski closed #741
  • Jan 13 03:28
    pkaminski commented #741
  • Jan 13 03:28
    pkaminski closed #795
  • Jan 13 03:28
    pkaminski commented #795
  • Jan 13 03:27
    Client build 4450 deployed
  • Jan 13 01:06
    anthonykawa assigned #788
  • Jan 12 14:53
    pkaminski assigned #783
  • Jan 12 08:27
    pkaminski closed #782
Piotr Kaminski
@pkaminski
@feldgendler If you're around, I have a few hours available starting now-ish.
Piotr Kaminski
@pkaminski
Given our offset timezones, perhaps it would make sense for you to prep a PR at the end of your workday so I could investigate in my morning time.
Marc Zych
@marczych

Are there any settings for not requiring review of files that only have base commit changes? We're getting some review fatigue from developers e.g. open PR, reviewer reviews all files, author merges the target branch, and the author asks the reviewer on slack to rubber stamp the slew of files that only have base commit changes.

I'm seeing baseCommitSha in the completion condition input but I suspect that it can't be used to detect when a file only has base commit changes since it was last reviewed. Any ideas?

4 replies
Alexey Feldgendler
@feldgendler
@pkaminski Alright, try this one: https://reviewable.io/reviews/ridge/tectonic/7685
Piotr Kaminski
@pkaminski
Thanks, could you please add screenshots of what you see on the dashboard and the review page for this PR?
Alexey Feldgendler
@feldgendler
It appears for me in “My Reviews” (“Created by me” section) with the number 3 in the unreviewed files column, but the PR actually has 8 unreviewed files.
Piotr Kaminski
@pkaminski
Just "3" not "3+", right?
Also, can you tell from eyeballing the review which number is accurate (if any)?
Alexey Feldgendler
@feldgendler
@pkaminski Yes, “3” on grey background.
The correct number is 8.
Piotr Kaminski
@pkaminski
OK, I see no review marks for any files/revisions, so that makes sense.
Could you please load the dashboard page with ?debug=model appended and report the value of truss.store.reviews['-MKLW60F3jteR--jiz2L'].files.num?
Piotr Kaminski
@pkaminski
(Particularly interested in estimate, reviewable, unreviewed, and toReview on that object.)
Piotr Kaminski
@pkaminski
@feldgendler ^^
Piotr Kaminski
@pkaminski
So it's suggestive that there are 3 changed files at r2 and all others carried over but I'll need the numbers above to help me trace the causality chain.
Alexey Feldgendler
@feldgendler
@pkaminski Of course, that PR is no longer in this state. I'll try to catch one more and will include the debug info.
Piotr Kaminski
@pkaminski
Note that the review will have a different ID that I'll need to look up for you.
Marc Zych
@marczych
Hi again. I have a PR that has commits that aren't shown in Reviewable despite multiple pushes to try to resync it. Is there a way to force resync a PR?
Also, a different PR didn't get the Reviewable button added to the PR description until I manually navigated to the review. Even then, the first few times displayed "Unable to create review: Request queued but server did not respond" but eventually it worked. I wonder if we're getting rate limited or there is some other issue with our GHE instance. Any ideas?
Piotr Kaminski
@pkaminski
@marczych It sounds like your Reviewable servers might be getting overwhelmed. Probably worth looking at queue health indicators in the logs, and poking around /queues/githubPullRequestSync in the Firebase console to see if any tasks have been attempted a large number of times. (For the review that just won't resync, it's also possible that you've run into a fatal crash driven by the data specific to that PR, so the task can't complete. You should look for "Repeatedly failed to process event" in the logs.)
9 replies
Marc Zych
@marczych
Great, thank you for the pointers!
Alexey Feldgendler
@feldgendler
@pkaminski Remember the issue we discussed above? I caught it again. Here is the debug info you wanted to see: Reviewable/Reviewable#794
Piotr Kaminski
@pkaminski
Thanks, on it!
Alexey Feldgendler
@feldgendler
Is Reviewable down? 
Timed out while waiting on cache-osl6528-OSL
On another attempt, got a 502 page with Google's logo.
Alexey Feldgendler
@feldgendler
Seems to be back to normal now.
Piotr Kaminski
@pkaminski
I don't recognize the cache host. Perhaps Firebase's hosting had a hiccup in your region, or some other local cache was interfering...
Piotr Kaminski
@pkaminski
Yep, it was likely this incident: https://status.firebase.google.com/incident/Hosting/20005#20005001
Børge Nordli
@bnordli
All new PRs in our organization are marked as "Archived" in the list. And trying to create the review by going to the usual link spins for a while until it returns "Unable to create review: Request queued but server did not respond"
(Existing reviews work as expected.)
Lukas Vogel
@lukedirtwalker
hello, is there a way to force sync github status with reviewable? For a PR I don't see the github updates in reviewable. but I see comments posted in reviewable in github.
Piotr Kaminski
@pkaminski
@lukedirtwalker Normally loading the review page will force a sync. However, there was an issue with some PRs starting yesterday that made them un-syncable. I fixed it a couple hours ago -- are you still seeing problems? If so, could you send me a sample PR link, either here or to support@reviewable.io? Thanks.
5 replies
@bnordli That's weird, but I think it might be the same issue I just fixed (see above). Is it still happening or are you good now?
Børge Nordli
@bnordli
Still happening, sending link in mail
Piotr Kaminski
@pkaminski
Thanks guys -- I think there's a bigger issue, I'm rolling things back so I have time to figure out what went wrong. Should be working again in a few minutes.
Børge Nordli
@bnordli
Works now, thanks for the quick roll back :)
Lukas Vogel
@lukedirtwalker
Also works for me yes, thanks.
Dan Halperin
@dhalperi
Multiple of us in different sites are getting Failed to publish: Request queued but server did not respond. I see github has some maintenance, though they claim it's just to GitHub Actions and should only result in delays.
Piotr Kaminski
@pkaminski
Looks like the server was having some issues around that time -- likely something on Google's side, since I haven't made any changes recently. Apologies for the late follow-up: traveling in Taiwan is great, but UTC+8 has its downsides.
Hmm, or perhaps it was a Reviewable-side event of some sort. CPU utilization spiked and we maxed out at 10 instances.
Piotr Kaminski
@pkaminski
Final analysis is that it was a burst of work that the servers couldn't scale fast enough to deal with. I'll raise the scaling limits to try to mitigate this in the future.
Dan Halperin
@dhalperi
:+1: thanks
Eran Sakal
@esakal
Hello! I love reviewable and use it daily. I joined a project that is currently on bitbucket, is this supported by reviewable?
Piotr Kaminski
@pkaminski
Hey @esakal, thanks for using Reviewable! Unfortunately, we don't have any current plans to support Bitbucket or any other platforms besides GitHub. (See Reviewable/Reviewable#293 and https://github.com/Reviewable/Reviewable/issues/456.)
Marc Zych
@marczych
Hey, is there any way to get some code review stats from Reviewable? For example, number of files/PRs that a given developer has reviewed in a given month? I'd rather not parse GitHub review comments to get this (Reviewed 5 of 5 files at r1.) so I'm wondering if there are any alternatives available or on the roadmap.
Piotr Kaminski
@pkaminski
@marczych Reviewable doesn't track stats internally, but you have two options. The simpler one is just to look at high-level stuff through GitHub's API (e.g., you should be able to get a "number of PRs developer commented on where they weren't an author" pretty easily, which would be a good proxy for "PRs reviewed"). In fact, GitHub themselves has an Insights product, and you can quickly find a number of third party solutions as well.
If you need finer-grained data, the other option is to hook up a sink to Reviewable's event firehose by configuring REVIEWABLE_ANALYTICS_URL. Events are posted in a JSON format that roughly follows Segment's tracking spec so there are likely tools that will be able to consume it directly (it's the closest to a "standard" I could find). I'd also be able to add more events pretty easily, architecture permitting.
Marc Zych
@marczych

I was originally thinking that number of files reviewed would be useful but we can probably use number of PRs as a reasonable proxy and use a third party solution for that. Maybe this one? https://github.com/Kimi-Gao/github-pr-analysis

Thanks!

Piotr Kaminski
@pkaminski
That looks like it would work, yep. You can definitely pull the number of files in the PR, so unless you need to know specifically how many files each person reviewed in a multi-party review it should be a good enough approximation. And if you're going to get more detailed than that you'd really want to know the diff sizes anyway...