lib/monitoring/context.go was renamed at r1 so it doesn't "exist" at that revision, but Reviewable is trying to pick that as the right diff bound anyway. Probably because it's a "mixed" file: its r1 was assimilated into a new renamed file, but it gets re-added at r3, so it's not completely gone.
TypeError: Cannot read property 'assimilated' of undefined
Dumb q: is it just me or did the highlighting of text change in the last few months?
I think that when I made a multiline selection in the past, reviewable would automatically expand the front of the selection to the entire first line, and maybe do the same for the end. Now it seems to be keeping my first line exactly where it was.
Is this an intended change? If so, fine - I can be more precise :)
event.target.closest being undefined that I kludged away, but perhaps broke things doing that...
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
?debug=model appended and report the value of truss.store.reviews['-MKLW60F3jteR--jiz2L'].files.num?
/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.)