My team is currently conducting reviews with pull requests in GitLab. Why would we need Collaborator for reviews?
For some teams, conducting code review through pull requests in GitLab is enough, especially for small changes. Conducting reviews in GitLab might be convenient, it does dramatically limit your team's code review process. Through its GitLab integration, Collaborator enables teams to customize their review process with custom fields, workflows, checklists, and participant rules. Your team can also specify comments versus defects so you can capture key metrics on your process, like defect type and severity, inspection rate, and lines of code reviewed, and use the review as a quality gate. Collaborator also lets your team go beyond just reviewing code, since it also supports document review. If you want to build a review process that includes multiple artifact types and drives continuous improvement, it is easy to integrate Collaborator with GitLab and ensure quality code is being merged.
When is a review created using the GitLab integration?
A review will be created when either a pull request or push/commit is made to a branch that Collaborator is told to track.
How do I get to the review in Collaborator once one has been created by the GitLab integration?
When a review is created by a pull request or push/commit, Collaborator will leave a comment with a link to the review on the pull request or push/commit.
Can I create a review for a pull request from Collaborator?
No – the review is created when the pull request event occurs in GitLab with a destination branch monitored by Collaborator. To ensure that reviews are created for all branches that need a review prior to merge, change your branch settings for that repositories integration.
Who’s account will the Collaborator review be associated with when it is created by the GitLab integration?
Collaborator will try to associate the GitLab user that initiated the pull request / commit with a Collaborator user. If the GitLab user name matches a Collaborator user name, the review will be created under that Collaborator account. If Collaborator cannot find any users that match the GitLab user name, it will check to see if any users have mapped their Collaborator user name to the GitLab user name; if it finds a match, the review will be created under that Collaborator account. If Collaborator cannot find any Collaborator users who match the GitLab user name, or are mapped to the GitLab user name, the review will be created under the Admin user.
As I continue to develop, can I update a review with new commits after a review is created?
If a review is created by a pull request, as you merge code into your pull request, the Collaborator review will be updated.
What happens if I perform rebasing operations on the commits involved in my pull request after a review is created?
The Collaborator review will update itself to match the git history of the pull request. For example, if you squash several commits in your pull request, the Collaborator review will reflect that. We will not remove comments left on versions of a file that have been rebased out of a review.
What happens if I merge in upstream changes to my pull request after a review is created?
The Collaborator review will update accordingly, and by default, will not highlight these changes in the diff viewer.
What happens when I leave comments on a GitLab PR? How about a Collaborator review?
Comments will propagate from GitLab to Collaborator, but will NOT propagate from Collaborator to GitLab.