Their previous arrangement made it so that the PR review case completely shadowed the PR review comment case, since strings.HasPrefix(cr.ID, "r") is always true whenever strings.HasPrefix(cr.ID, "rc") is true.
It's possible for messages with the "autogenerated:gerrit:newPatchSet" tag to also set labels, which wasn't previously supported. E.g.: Uploaded patch set 4: Run-TryBot+1. (1 comment) Or: Uploaded patch set 5: Run-TryBot+1. Update the code to handle these.
Some messages with the "autogenerated:gerrit:newPatchSet" tag have a different format than previously expected: Patch Set 3: Commit message was updated. I'm not aware that such messages could have inline comments, so handle them by looking for a "Patch Set " prefix, and stop there. No need to do more for now.
Previously, GitHub itself did not support leaving reactions on Pull Request reviews. It was only possible to leave reactions on normal comments and inline review comments. They've added that feature now, so this change implements it accordingly in this package. Reference: https://developer.github.com/v4/changelog/2019-01-11-schema-changes/.
In Gerrit, it's possible to publish inline comments on patchset push. Such messages look like this: Uploaded patch set 2. (3 comments) Parse and display such comments.
Use the more explicit project~id change ID format. It's not deprecated, and lets us detect and return a not exist error when the project doesn't match the CL. Previously, just the numeric change ID was used. That format is deprecated, and doesn't tell us when the project doesn't match the CL. References: • https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-id • https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#change.api.allowedIdentifier
The issue https://golang.org/issue/21358 has been resolved upstream, so there's no more need to use a temporary fork of the ctxhttp package.
Still manually crafted in order to prototype and learn about this space. It's still not completely clear how to best integrate patch sets vs multiple commits, the commit messages, and how git client fits into the picture. The end result can be seen at https://dmitri.shuralyov.com/gpu/mtl/...$changes/1.
Also remove commented out sort code. It's normal and expected for Gerrit IDs not to line up with created times. As documented at https://godoc.org/golang.org/x/build/maintner#GerritCL.Number: > Number is the CL number on the Gerrit server (e.g. 1, 2, 3). Gerrit CL > numbers are sparse (CL N does not guarantee that CL N-1 exists) and > Gerrit issues CL's out of order - it may issue CL N, then CL (N - 18), > then CL (N - 40).
This helps with displaying large PRs that have over 100 timeline items (e.g., https://github.com/neelance/go/pull/7). The implementation is based the similar issues service ListTimeline, see https://github.com/shurcooL/issues/commit/4081aa59e957752abbfc6b6fdab72c3bbc1c1dec.
Previously, the review state wasn't correctly parsed when there was more than 1 label (e.g., "Run-TryBot+1 Code-Review+2"). Example of an affected review is https://go-review.googlesource.com/c/go/+/112935#message-45e0d04e5f087880438b34c77b6b683f0beffaa3.
We need to fetch messages in Get method, so that counting them works. Previously, len(chg.Messages) was always zero, and so was Replies as a result. Make project helper implementation simpler by making its error handling path indented, and the normal execution path not indented.
Make it more consistent across the services.
A CL is considered to not exist if it's private or if it has an empty status (possible due to an upstream bug). Updates https://golang.org/issue/22060.
This is more robust. It also removes the need to talk to real GitHub API while creating a new service, which is undesirable during testing. Analogous to https://github.com/shurcooL/issues/commit/adf13e46e3d966ef14ee08722b56b823cf5c3f3b.
Previously, it panicked. Now that I have a better how to deal with it, add a comment describing the state. For now, skip such reviews. In the future, can display them with a pending/draft style.
Similar to https://github.com/shurcooL/issues/commit/697ee8e877735feed6151525cad859327bfe40c4. Follows https://dmitri.shuralyov.com/state/...$commit/28bcc343414c6adcd7b6911f9d0ef1ad6fbf30ae and https://github.com/shurcooL/events/commit/25a0212309664cda69930a58f8369f24b9029812.
Change timeline item ID type from uint64 to string.
Add unparsed messages as simple comments. This way, value of Replies corresponds to actual number of messages.
Page size 100 is largest allowed. Add full pagination later if/when needed.
It can't be set in Go 1.10 due to reflect changes. Also switch from githubqlActor to githubqlUser because RequestedReviewer union is known to be User or Team, so Actor interface is unnecessarily broad. References: - https://tip.golang.org/doc/go1.10#reflect - https://developer.github.com/v4/union/requestedreviewer/ - https://developer.github.com/v4/interface/actor/
Detect ghost actors/users via them missing entirely, rather than checking for zero DatabaseID. This is consistent with how GitHub GraphQL returns them at this time. Fix minor miscounting issue in reactions method. Remove unneeded error return parameter from reactions method. These changes help keep the code more consistent with issues/githubapi package.
It's needed because in some meta-services that unify multiple underlying services, the ThreadType changes depending on the RepoSpec. Similar to https://github.com/shurcooL/issuesapp/commit/60bf33177c6943f244f14f81f145bc8b6c63f6cc.
There's no longer a clean distinction between comments and events. There are other timeline item types that don't fit into either category cleanly. Also, underlying implementations for various APIs are very similar and have overlap. As a result, it makes sense to merge these two methods into one.
Remove ListCommitsOptions from ListCommits. Expected usage is to always get all commits, then find the one you're interested in. This is what's needed to implement prev/next commit buttons, and more closely matches what's returned by 3rd party APIs. The button styling can be improved; to be done later.