Bitbucket Server (On-Premise) Integration

Applies to Collaborator 13.5, last modified on December 21, 2021

About

  • You use the Bitbucket Server (On-Premise) integration to track changes in repositories stored at your Bitbucket Server.

    Collaborator can work with repositories of both Git and Mercurial types.

    Collaborator's Bitbucket integration will no longer be able to support Mercurial starting on June 1, 2020, when Atlassian will officially remove Mercurial features and repositories from Bitbucket and its API.

    Bitbucket Server version 5.4 or later is supported.

  • When you integrate Collaborator with some Bitbucket Server repository, your Collaborator server creates reviews automatically for pull requests in that repo, as well as for push events that occur in that repo. For complete information on what the integration means and how you can benefit from it, see Integration With Repository Hosting Services.

  • To inform Collaborator about changes, Bitbucket Server uses a webhook that sends notification messages to your Collaborator server.

  • To set up the webhook and other integration parameters, you need to set up some options in Collaborator and in Bitbucket Server. See below for details.

  • Do not confuse Bitbucket Server (On-Premise) and Bitbucket integration types. Use the Bitbucket Server type to track changes in repositories stored on your Bitbucket Server. To integrate with repositories stored at the bitbucket.com website, use the Bitbucket integration type.

Requirements

  • Your Collaborator server must be accessible to your Bitbucket server and vice versa. You may need to configure your firewall or enable tunneled connections to expose the server’s External URL to your Bitbucket server. If needed, ask your system administrator for help.

  • To configure integration settings in Collaborator, you need Administrator privileges.

  • Also, you need to know the user name and password of the administrator user on your Bitbucket server.

1. Set up integration

Collaborator offers two groups of settings for configuring integration with remote repositories:

Settings When to use
Easy Add Repository tab We recommend using these settings to set up new connections to your repositories quickly.
Configure Remote Systems tab Use these settings to configure existing connections. Though you can use these settings to set up integration, the settings on the “Easy Add Repository” tab will help you do this faster.

Additionally, you can create auto-polling configuration to periodically look for new repositories on the specified server and suggest creating integrations for them.

Easy Add Repository tab (recommended)

  1. Log in to Collaborator as administrator. (To integrate with Bitbucket server, you need administrator privileges in Collaborator).

  2. On the Collaborator main toolbar, click ADMIN, and then select Repository Hosting Services from the tree on the left. Then switch to the Easy Add Repository tab.

  3. On the tab, select Bitbucket Server (On-Premise) in the Add repository for box and click Next:

    Integration with Bitbucket Server: Start

    Click the image to enlarge it.

  4. Collaborator will displays a page with connection details.

    Fill in the edit boxes:

    Integration with Bitbucket Server: Settings

    Click the image to enlarge it.

    Setting Description

    Admin username

    Required. The user name of the Bitbucket Server administrator.

    Admin password

    Required. The password of the Bitbucket Server administrator.

    Host name

    Required. Denotes the host name of your Bitbucket Server.

    Override existing configurations

    Optional. Specifies whether to override existing configurations that track the same repository URI.

    Branches to track

    Optional. The names of branches to track changes and create reviews on pull requests and direct pushes. Separate multiple branch names with commas.

    You can use Java-style regular expressions to match specific branch names, or you can use the * wildcard (alone, or separated by commas) to match all branches.

    If this field is empty, main branch of the repository will be tracked (main for repos of the Git type and default for repos of the Mercurial type).

    Ignore pushes for branches

    Optional. Specifies branches for which Collaborator will not create reviews on direct pushes.

    You can enter one or several branch names. Separate multiple branch names with commas. You can also use Java-style regular expressions to match specific branch names, or you can use the * wildcard (alone, or separated by commas) to match all branches.

    When review completed

    Optional. Specifies an action to perform when a review corresponding to the pull request was accomplished:

    Value Description
    Do nothing Do not perform any action.
    Merge the pull request Merge the pull request that matches the review.
    Merge the pull request and delete its branch Merge the pull request that matches the review and delete the corresponding branch.
    Close the pull request Close the pull request that matches the review.
    Close the pull request and delete its branch Close the pull request that matches the review and delete the corresponding branch.

    When review cancelled/deleted/rejected

    Optional. Specifies an action to perform when a review corresponding to a pull request was cancelled, deleted or rejected:

    Value Description
    Do nothing Do not perform any action.
    Close pull request Close pull request that matches the review.
    Close pull request and delete its branch Close pull request that matches the review and delete the corresponding branch.

    Reopen a review when

    Optional. Specifies in what cases Collaborator should reopen completed reviews. May include any combination of the following:

    • when a push to a pull request is made,
    • when a comment is added to a pull request,
    • when a comment is added to commit which is a part of a pull request
  5. After you specified the settings, click Load repositories. This will display a list of repositories on the specified Bitbucket server. Select the repositories to track and click Create for selected.

    Alternatively, you can click Create for all and use the settings for all the available repositories. Collaborator will create an individual configuration for each repository, and will create a webhook for each repo.

Configure Remote Systems tab

  1. Log in to Collaborator as an administrator. (To configure integration settings, you need administrator privileges in Collaborator).

  2. On the Collaborator main toolbar, click ADMIN, and then select Repository Hosting Services from the tree on the left. Then switch to the Configure Remote Systems tab.

  3. In the New Remote System Configuration section, select Bitbucket Server (On-Premise) and click Create:

    Integration with Bitbucket Server: Start

    Click the image to enlarge it.

  4. Collaborator will display a page with configuration settings. Specify the setting values:

    Setting Description

    Title

    Required. The configuration name as it will be displayed in Collaborator user interface.

    Bitbucket repo URI

    Required. The URI of the desired repository on your Bitbucket Server, for example, http://hostname/projects/PROJ/repos/my_repo.

    You should copy the repository URI from the browser’s address bar, rather than from the repository’s clone URI.

    Both Mercurial and Git repositories are supported.

    Admin username

    Required. The user name of the Bitbucket Server administrator.

    Admin password

    Required. The password of the Bitbucket Server administrator.

    Branches to track

    Optional. The names of branches to track changes and create reviews on pull requests and direct pushes. Separate multiple branch names with commas.

    You can use Java-style regular expressions to match specific branch names, or you can use the * wildcard (alone, or separated by commas) to match all branches.

    If this field is empty, main branch of the repository will be tracked (main for repos of the Git type and default for repos of the Mercurial type).

    Ignore pushes for branches

    Optional. Specifies branches for which Collaborator will not create reviews on direct pushes.

    You can enter one or several branch names. Separate multiple branch names with commas. You can also use Java-style regular expressions to match specific branch names, or you can use the * wildcard (alone, or separated by commas) to match all branches.

    When review completed

    Optional. Specifies an action to perform when a review corresponding to the pull request was accomplished:

    Value Description
    Do nothing Do not perform any action.
    Merge the pull request Merge the pull request that matches the review.
    Merge the pull request and delete its branch Merge the pull request that matches the review and delete the corresponding branch.
    Close the pull request Close the pull request that matches the review.
    Close the pull request and delete its branch Close the pull request that matches the review and delete the corresponding branch.

    When Review cancelled/deleted/rejected

    Optional. Specifies an action to perform when a review corresponding to a pull request was cancelled, deleted or rejected:

    Value Description
    Do nothing Do not perform any action.
    Close pull request Close pull request that matches the review.
    Close pull request and delete its branch Close pull request that matches the review and delete the corresponding branch.

    Reopen a review when

    Optional. Specifies in what cases Collaborator should reopen completed reviews. May include any combination of the following:

    • when a push to a pull request is made,
    • when a comment is added to a pull request,
    • when a comment is added to commit which is a part of a pull request

    Wait for signature (if enabled) before merge

    Optional. Effective, if "When review completed" setting is set to "Merge the pull request" or "Merge the pull request and delete its branch".

    If enabled Collaborator will wait for the completed review to be signed off before merging the respective pull request. Otherwise, pull request will be merged immediately, even if the review have not been signed yet.

    Webhook status

    Indicates the current status of the webhook:

    Status Description
    Webhook is absent The webhook has not been created yet.
    Webhook isn't active The webhook has been created, but is inactive.
    Up and running The webhook is active.
  5. To create or activate a webhook, click Update webhook.

    Important: Click this button, when you set up integration with your repository for the first time.

    To learn more about webhook settings on the Bitbucket side, see Bitbucket documentation:

    https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html

  6. Click Test Connection to verify if you entered data correctly.

    Click Save to store the settings.

Creating Bitbucket auto-polling configuration

Sections above describe how to add integrations for existing repositories. When some new repositories are created on a server, you may integrate them manually. Alternatively, you can setup Bitbucket auto-polling configuration that will periodically look for new repositories on the specified server, user, workspace or project and suggest creating integrations for them.

  1. Log in to Collaborator as administrator. (To integrate with Bitbucket repositories, you need administrator privileges in Collaborator).

  2. On the Collaborator main toolbar, click ADMIN, and then select Repository Hosting Services from the tree on the left. Then switch to the Repository Auto-Polling tab.

  3. On the tab, select Bitbucket in the Add configuration box and click Next.

  4. Collaborator will displays a page with connection details.

    Integration with Bitbucket: Auto-polling Settings

    Click the image to enlarge it.

    Fill in the edit boxes:

    Setting Description
    Server URI Required. The URI of Bitbucket server, user, workspace or project to be polled for new repositories.
    Username

    Required. Specifies the user account name for single-user repositories, or an account name to use for authentication in Team repositories.

    Password

    Required. The password for the Bitbucket account to be tracked.

    User role

    Optional. Defines which types of repositories to track:

    Value Description
    Owner (default) Repositories that are owned by the specified user.
    Admin Repositories to which the user has administrator access.
    Member Repositories to which the user has read access.
    Contributor Repositories to which the user has write access.

    Webhooks will be created for those repositories where allowed by the repository permissions for the specified user.

    After specifying these values, you can click Test connection to verify if you entered data correctly.

  5. After you specified the values, click Save. This will create an auto-polling configuration and display it in the Auto-Polling Configurations List.
  6. Scroll down the Repository Auto-Polling tab and check that the Enable Auto-Polling setting is on and optionally change the Auto-Polling Interval setting.

Now Collaborator will automatically check if any new repositories were found on the specified server. Once found, it will notify administrators and suggest creating integrations with these newly created repositories via the Easy Add Repository wizard.

Known Issues and Specifics

  • You can specify Bitbucket users as reviewers when you are creating a pull request. If your teammates link their Bitbucket accounts with their Collaborator accounts correctly, then Collaborator will automatically add those users as reviewers to the created review on the Collaborator side.

  • Due to certain limitations on the Bitbucket Server side, Collaborator is unable to create reviews, if paths of submitted files contain the percent symbol (%).

  • To avoid creating reviews for merge commits, keep their messages default or start them with the Merged in substring.

  • If the remote repository server is not accessible, Collaborator will retry connecting after a certain time period and will perform several retry attempts. Wait time is increased with each attempt: wait_time*1, wait_time*2, wait_time*3 and so on. Default wait time is 1 second and Collaborator will perform 3 retries. Wait time and maximal number of attempts could be configured via Java VM Options. If the server did not respond after all attempts, Collaborator will mark the respective webhook as inactive and put an exception to the remoteSystem.log

  • In order to create reviews on pull requests from forked repositories, the following conditions must comply:

    • Forked repository of the same repository owner can be public or private.
    • Forked repository of a different repository owner must be public repository.

See Also

Source Control Integrations
Bitbucket Integration

Highlight search results