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

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 contains a link to the remote repository.

Click the image to enlarge it.

Reviews do not include comments that users make to pull requests in repository hosting services. Similarly, comments of review participants are not added to pull requests.

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 the new review to that Collaborator user and logs that user as a review creator. If Collaborator does not find a matching user, it assigns the review to the Collaborator administrator and logs the administrator as a review creator.

• 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.