v1.6.10

v1.6.9 got siGit Code Review answering replies on GitHub. The first day of that showed a second problem: after accepting a reply, the reviewer tried to resolve the thread, GitHub refused, and the run stopped there. Later threads on the same pull request went unanswered and the approval never came.

#The reviewer does not resolve threads on GitHub

GitHub only lets an App resolve a review thread if it can write to the repository's contents. The siGit Code App can read your code and comment on it, and cannot change it. We are keeping it that way, so the reviewer no longer tries to resolve.

Its reply is its last word on a thread: a short accept, a defer after three turns, or "Looks fixed" after a push. The thread stays open for you to resolve. On sigit.si, where no such permission is involved, it still resolves the threads it closes.

#Approval follows the reviewer's verdict

The reviewer used to approve once every thread above a nit was resolved or outdated. A thread now also counts when the reviewer accepted or deferred and nobody has written in it since, so the approval arrives without waiting for anyone to click resolve. A new comment in the thread reopens the question.

#Replies that were left waiting

Replies posted before v1.6.9 could not be matched to a thread, and backfilling the comment ids did not go back and answer them. A new task, code_review:answer_waiting_replies, runs the follow-up on recent pull requests, and the backfill now starts it whenever it attaches ids.

#A check on the App's permissions

code_review:check_permissions compares what the App holds on GitHub with what the reviewer is meant to hold, and fails if it has more.

---

Release masters: @setoelkahfi and @sigit.