Integration With Repository Hosting Services

After you configured integration settings, Collaborator tracks changes in one or several branches of your repository (you specify the branches to track and to ignore when configuring integration settings in Collaborator).

Collaborator automatically creates reviews in the following cases:

• When it detects a pull request to the tracked branch (in some systems, pull requests are called merge requests).

• When it detects push events (commits, not pull requests) to the tracked branch.

Collaborator uploads the copies of changes files to the review and assigns the review to the respective user. On the repository side, it registers the review as a CI test for the pull request (in GitHub terms, these are called status checks, in GitLab — pipelines, in Bitbucket and Bitbucket Server — builds). So, you can see the status of the created review in the pull request details:

See examples

See examplesSee examples

• GitHub
• GitLab
• Bitbucket
• Bitbucket Server
• Azure DevOps

Click the image to enlarge it.

Click the image to enlarge it.

Click the image to enlarge it.

Click the image to enlarge it.

Click the image to enlarge it.

For protected branches, you have to complete Collaborator reviews before closing the pull request.

Collaborator also automatically creates reviews for changes in submodules (or subrepositories). See below.

The new review includes changes made to the remote repository. Namely —

• When creating a new review, Collaborator automatically uploads copies of the pull request’s or commit’s files to the review. That is, the review contains the modified files, not the file links or commit IDs. You can see these files in the Review Materials section of the review.

• The Remote System Links section contains the links to pull requests or commits, as well as their current statuses.

• The Chat section would display a link to the remote repository, names of pull request branches, pull request description (if provided) and comments that users made to pull request/commit on the remote repository side.

Click the image to enlarge it.

The initial phase of the newly created review will be Planning, so authors could check the review, add notes or upload additional materials before notifying other participants. Alternatively, Collaborator administrators can enable the Move pull request reviews to Inspection setting to start reviews automatically. In this case Collaborator will verify if the review meets the workflow requirements (for example, has minimal number of participants) and will move it to the Inspection phase on success.

When Collaborator gets a notification about changes in a repository, it also gets information about the source-control user, who made these changes. So, it attempts to find a corresponding user in Collaborator to assign the new review to that user. In order for the search to be successful, you and your teammates need to link their Collaborator and source-control accounts in Collaborator settings. See Link User Accounts for details.

If Collaborator finds a Collaborator user that matches the source-control user, it assigns that Collaborator user as a review author and creator. If Collaborator does not find a matching user, it assigns the Collaborator administrator as a review author and creator.

Additionally, Collaborator can assign reviewers in the following cases:

• GitHub, GitLab: If repository contains a CODEOWNERS file that defines users responsible for certain files in a repository and integration can match those GitHub/GitLab users with Collaborator users,
• GitHub: If some specific users were added as reviewers when creating pull request on the GitHub side and integration can match those GitHub users with Collaborator users, and the Auto assign reviewers option is on.
• GitHub: If some team was added as reviewer when creating pull request on the GitHub side, or some team was specified in CODEOWNERS file and integration can match members of that team with Collaborator users, and the Auto assign reviewers option is on.
• Bitbucket, Bitbucket Server: If some specific users were added as reviewers when creating pull request on the Bitbucket side and integration can match those Bitbucket users with Collaborator users.
• Azure DevOps: If some specific users were added as reviewers when creating pull request on the Azure DevOps side and integration can match those Azure DevOps users with Collaborator users, and the Auto assign reviewers option is on.

• If a review was created for a pull request

  If your teammates make more changes to the branch after a review was created, and if the pull request is not closed, Collaborator uploads new file versions to the created review. This works until the pull request is closed. If the review remains open after the pull request is closed, then Collaborator will not upload files from subsequent commits to the review.

• If a review was created for a commit (push event)

  Collaborator will not upload new file versions to the review automatically.

If a file conflict can be resolved automatically, Collaborator will not add any new file copies to the review. If a file conflict needs to be resolved manually (that is, if some files are to be changed to complete the merge request), then Collaborator will update the review with newer file versions.

... file changes made by merge commits will only be displayed in Separate view of the Review Materials section of the review. They will not be displayed in Overlay view. Besides, file changes made by merge commits are not taken into account when calculating overall LOC metrics and they do not affect the overall rework count of a file.

... Collaborator will process the outdated commits and will reorder the list of file revisions to keep it up-to-date.

• If some file revisions have been removed, the comments or defects addressing that file revision will be promoted to resulting revision and will display a special icon indicating that the comment/defect could be outdated.
  
  
• If some files have been removed, they will also be removed from the review materials. For audit purposes, comments and defects for removed files will be copied to the review's general chat.
  
  

... Collaborator can automatically merge or close the appropriate pull request. This behavior is controlled by the When review completed option that you set when integrating Collaborator with your repository.

... the review can be reopened. The Reopen a review when option allows selecting what events should reopen the review.

... Collaborator can automatically close the corresponding pull request. Additionally, it can automatically delete the corresponding branch. This behavior is controlled by the When Review Cancelled/Deleted/Rejected option that you set when integrating Collaborator with your repository.

... Collaborator posts a comment to the corresponding review.

It is quite possible, that the pull request, for which a review was created, is reopened after that review was completed. In this case, Collaborator will reopen the review.

If review was canceled, deleted or rejected and if the pull request is reopened, Collaborator creates a new review.