About
-
You use the Bitbucket integration to track changes in repositories stored at the bitbucket.org website.
-
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.
-
When you integrate Collaborator with a Bitbucket 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. See below for details.
-
Do not confuse Bitbucket and Bitbucket Server (On-Premise) integration types. Bitbucket Server is a self-hosted version of Bitbucket. To integrate with it, use the Bitbucket Server (On-Premise) integration type.
Requirements
-
Your Collaborator server must be accessible to Bitbucket and vice versa. You may need to configure your firewall or enable tunneled connections to expose the server’s External URL to the Web. If needed, ask your system administrator for help.
-
Note that Collaborator makes API calls to https://api.github.com which is a machine separate from https://github.com. When using trusted connections, ensure that the security certificates from both machines are accepted.
-
To configure integration settings in Collaborator, you need Administrator privileges.
- Bitbucket has deprecated their API 1.0 on 29th of April 2019. You will need to upgrade to Collaborator version 11.5.11502 or later to use Bitbucket integration.
1. Get Bitbucket App Password
To integrate Collaborator with Bitbucket, you need an app password that will be used to access your repository. For detailed information on generating app passwords, follow instructions on this page of Bitbucket documentation:
Notes:
-
When creating an app password, make sure to enable the following permissions:
-
In the Repositories category:
- Read
- Write
- Admin
-
In the Pull requests category:
- Read
- Write
-
In the Webhook category:
- Read and write
-
-
After Bitbucket generates the app password, it will display it on screen. Save the app password somewhere or write it down. You will need it later, when you will configure the integration between Collaborator and Bitbucket.
2. 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. |
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)
-
Log in to Collaborator as administrator. (To integrate with Bitbucket repositories, you need administrator privileges in Collaborator).
-
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.
-
On the tab, select Bitbucket in the Add repository for box and click Next:
-
Collaborator will displays a page with connection details.
Specify settings in the the following sections of the wizard:
Connection settings
Setting Description Team name
Required only for team owned repositories (https://bitbucket.org/TeamName/RepoName). Specifies the name of your Bitbucket team account (TeamName).
User role
Optional. Defines which types of repositories to track:
- Owner: Repositories that are owned by the specified user. (Default)
- 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.
Username
Required. A name of user account to use for authentication.
For single-user repositories (https://bitbucket.org/UserName/RepoName), this should be the user account name (UserName).
For team owned repositories (https://bitbucket.org/TeamName/RepoName), this should be the name of user account who belongs to the desired team.
App password
Required. The app password for a Bitbucket account that has access to the remote repository.
This is the password that we generated in Bitbucket earlier.
After specifying connection settings, you can click Load repositories to retrieve a list of repositories available for the specified user or team.
Select repositories
Select repositories
Optional. Displays a list of repositories available for the specified user or team.
Select which repositories you need to track. Use Ctrl+click or Shift+click for multi-selection.
If any of the repositories were chosen, the wizard will display the Create for selected button below the settings section.
If none of the repositories were chosen, the wizard will display the Create for all button below the settings section.
Override existing configurations
Optional. Specifies whether to override existing configurations that track the same repository URI.
Branches
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. Note that wildcards and regular expressions cannot be used if you enable the Status check required setting (see below).If this field is empty, main branch in the repository will be tracked (main for Git repositories and default for Mercurial repositories).
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.Pull request actions
Create review automatically
If enabled, reviews for pull request are created automatically.
If disabled, user can add pull request to a review manually through Remote System links, by API call or by special command directly from pull request.
When review completed
Optional. Specifies an action to perform when a review corresponding to the pull request was accomplished:
- Do nothing: Do not perform any action.
- Merge pull request: Merge pull request that corresponds to a review.
- Merge pull request and close its branch: Merge pull request that corresponds to a review and then close the respective branch.
- Squash pull request: Squash and merge pull request that corresponds to a review.
- Squash pull request and close its branch: Squash and merge pull request that corresponds to a review and then close the respective branch.
- Merge and fast forward pull request: Merge and fast forward pull request that corresponds to a review.
- Merge and fast forward pull request and close its branch: Merge and fast forward pull request that corresponds to a review and then close the respective branch.
To learn more about pull request merge strategies, see Bitbucket documentation.
Allow users to select merge strategy in review
If enabled, regular users would be able to choose pull request merge strategies in each separate review.
If disabled, all pull requests would behave as specified by the When review completed setting.
Wait for signature (if enabled) before merge
Optional. Effective, if any of merge actions (merge or squash) was selected in When review completed setting.
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.
Allow to complete review with conflicts in pull request
Should it be possible to complete a review if there are conflicts in the respective pull request.
When review cancelled/deleted/rejected
Optional. Specifies an action to perform when a review corresponding to a pull request was cancelled, deleted or rejected:
- Do nothing: Do not perform any action.
- Decline pull request: Decline pull request that corresponds to a review.
Auto assign reviewers
Whether to assign Collaborator reviewers when some specific users or teams were added as pull request reviewers or specified as code owners on the Bitbucket side and integration can match those Bitbucket users with Collaborator users.
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
Review settings
Default review template
Optional. Specifies the initial template that will be chosen when creating review (if set to "None", the first template in the list will be chosen).
The value of this setting overrides the value of Default review template setting specified on group level.
-
Click the Create for selected button or the Create for all button to create repository integrations and automatically create webhooks for each repository in Bitbucket. To stop suggesting integrations for some specific repositories, select these repositories in the list and click Ignore selected.
For every repository a separate configuration will be created in Collaborator and a webhook will be automatically added in Bitbucket.
Configure Remote Systems tab
-
Log in to Collaborator as an administrator. (To configure integration settings, you need administrator privileges in Collaborator).
-
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.
-
In the New Remote System Configuration section, select Bitbucket and click Create:
-
Collaborator will display a page with configuration settings. Specify settings in the following sections:
Bitbucket settings
Setting Description Title
Required. The configuration name as it will be displayed in Collaborator user interface.
Bitbucket repo URI
Required. The URI of the Bitbucket repository to be tracked, for example,
https://[email protected]/johnsmith/repo.git
.You can copy the URI from the repository settings in Bitbucket:
App password
Required. The app password of the Bitbucket account that has access to the repository.
This is the password that we generated in Bitbucket earlier.
Username for authentication
Required. Specifies an account name to use for authentication. For single-user repositories, account name is taken from the repo URI.
Webhook status
Indicates the current status of the webhook:
- 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.
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.
Branches
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. Note that wildcards and regular expressions cannot be used if you enable the Status check required setting (see below).If this field is empty, main branch in the repository will be tracked (main for Git repositories and default for Mercurial repositories).
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.Pull request actions
Create review automatically
If enabled, reviews for pull request are created automatically.
If disabled, user can add pull request to a review manually through Remote System links, by API call or by special command directly from pull request.
When review completed
Optional. Specifies an action to perform when a review corresponding to the pull request was accomplished:
- Do nothing: Do not perform any action.
- Merge pull request: Merge pull request that corresponds to a review.
- Merge pull request and close its branch: Merge pull request that corresponds to a review and then close the respective branch.
- Squash pull request: Squash and merge pull request that corresponds to a review.
- Squash pull request and close its branch: Squash and merge pull request that corresponds to a review and then close the respective branch.
- Merge and fast forward pull request: Merge and fast forward pull request that corresponds to a review.
- Merge and fast forward pull request and close its branch: Merge and fast forward pull request that corresponds to a review and then close the respective branch.
To learn more about pull request merge strategies, see Bitbucket documentation.
Allow users to select merge strategy in review
If enabled, regular users would be able to choose pull request merge strategies in each separate review.
If disabled, all pull requests would behave as specified by the When review completed setting.
Wait for signature (if enabled) before merge
Optional. Effective, if any of merge actions (merge or squash) was selected in When review completed setting.
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.
Allow to complete review with conflicts in pull request
Should it be possible to complete a review if there are conflicts in the respective pull request.
When review cancelled/deleted/rejected
Optional. Specifies an action to perform when a review corresponding to a pull request was cancelled, deleted or rejected:
- Do nothing: Do not perform any action.
- Decline pull request: Decline pull request that corresponds to a review.
Auto assign reviewers
Whether to assign Collaborator reviewers when some specific users or teams were added as pull request reviewers or specified as code owners on the Bitbucket side and integration can match those Bitbucket users with Collaborator users.
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
Review settings
Default review template
Optional. Specifies the initial template that will be chosen when creating review (if set to "None", the first template in the list will be chosen).
The value of this setting overrides the value of Default review template setting specified on group level.
-
Click Test Connection to verify if you entered data correctly.
Click Save to store the settings.
Click on Update Webhook button to add webhook for the repository on the remote system's side.
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.
-
Log in to Collaborator as administrator. (To integrate with Bitbucket repositories, you need administrator privileges in Collaborator).
-
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.
-
On the tab, select Bitbucket in the Add configuration box and click Next.
-
Collaborator will displays a page with connection details.
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.
This is the password that we generated in Bitbucket earlier.
User role
Optional. Defines which types of repositories to track:
- Owner: Repositories that are owned by the specified user. (Default)
- 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.
- After you specified the values, click Save. This will create an auto-polling configuration and display it in the Auto-Polling Configurations List.
- 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.
3. Link Collaborator User Account to Bitbucket Account
The last step is to link Collaborator user accounts to the Bitbucket accounts. See —
Note: When linking accounts, enter the Bitbucket name as it is specified in the Name field of the Bitbucket settings.
Enable/Disable configuration
Once a new repository configuration is created, it is enabled automatically. However, you can enable and disable integration with Bitbucket manually. To do this:
- In Collaborator, go to ADMIN > Integrations.
- In the Integration Status section find the Enable Bitbucket Integration setting and change it to Yes or No, respectively.
Known Issues and Specifics
-
When configuring user remote accounts, user names must be entered as specified in the Name field of the Bitbucket settings.
-
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.
-
To create reviews on pull requests for forked repositories, the following conditions should met:
-
Forked repository of the same repository owner can be public or private.
-
Forked repository of a different repository owner must be public repository.
-
-
Collaborator will not create reviews on merge commits of pull requests when their merge commit message starts with the Merged in substring or when merge commit message was specified in the Pull Request Merge Info section.
-
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
-
Right after you set up integration with some Bitbucket repo, Collaborator will not track the very first push or pull request to this repo. Subsequent requests will be tracked as they should be tracked.
-
The first push or pull request to a newly created branch will be tracked only if that branch was started from the main branch. As a workaround, create new branches without commits — the subsequent push events will be tracked as they should be.
See Also
Bitbucket Server (On-Premise) Integration
Source Control Integrations