Global Configurations for Bitbucket admins
Get started guide for Bitbucket administrators.
This guide is for Post Webhooks for the Bitbucket Atlassian Marketplace application.
Configuration
To start the Post Webhooks for Bitbucket plugin configuration you have to add a new webhook on the Global configuration page:
Move to the Bitbucket Administration section (“gear” button in the right corner of the navigation menu).
From the sidebar on the left, navigate to the Add-ons section and select our application Post Webhooks.
From the Configurations tab, click
After you have specified all the necessary parameters click on the Save button.
On the Configurations tab, you also can see all webhooks created on the repository and project levels. On Global level you can set up only 1 configuration .
Below you can find a short definition of each parameter you have to specify:
Parameter | Definition |
---|---|
| resourse where the data should be sent. Also you have to specify the HTTP method to be used when making requests to the target URL:
|
| by enabling this parameter the app will allow you to use URLs that may not conform to the standard validation rules |
| the app adds an authentication mechanism to the webhook requests, ensuring that only authorized parties can access the webhook endpoint. By enabling this option you have to specify:
Kerberos authentication is available since 3.22.12
|
| enabling mutual TLS ensures that only trusted clients with valid and verified certificates can establish a connection with the webhook endpoint. By enabling this option you have to specify folowing parameters:
|
| this parameter instructs the app to skip the validation of SSL certificates, allowing the connection to be established even if the certificate cannot be verified. |
| allows you to specify which payload type should be sent. Supports:
The Azure DevOps pipeline that should be triggered when the webhook event occurs. By enabling this option additionality you have to specify folowing parameters:
To trigger GitHub workflow use the following parameters,
CODE
Find more details on GitHub workflow integrations with Bitbucket here |
| allows you to specify the type of events that should trigger the webhook |
| the comma-separated list of Bitbucket branch regular expressions that should be considered when filtering events. For instance, |
| the comma-separated list of Bitbucket branch regexes that should be ignored. |
| allows you to specify the type of events that should trigger the webhook |
| the comma-separated list of Bitbucket branch regexes that should be included |
| the comma-separated list of Bitbucket branch regexes that should be ignored. |
| the comma-separated list of Bitbucket user names that should NOT trigger an event. This is often used to ignore pushes from your continuous integration user. Important: not display names, but usernames. For instance, |
| comma-separated list of file paths, only commits on these file paths will trigger the webhook. For example, |
| a pattern or regular expression that defines the repositories for which the webhook should be triggered. Commits on these repositories will trigger this hook. For instance, |
| skip triggering events for commits/pull requests that include the |
| skip the events that occur in forked repositories. |
| comma-separated list of Bitbucket project keys that will trigger this event. |
| comma-separated list of Bitbucket project keys that will be IGNORED for this event. This could be used with the combination of Include projects empty (include all). |
| the name of the configuration Our advice is to name something meaningful to you and your team so that it can be understood later easier. |
| Disable to prevent this ruleset being active |
Once the webhook has been created, you can start using app. The rest configurations are optional to make your integrations more streamlined and efficient.
A table of created webhooks provides a centralized view of all webhooks configured across your Bitbucket instance. It allows you to see the complete list of webhooks in one place, making it easier to manage and monitor them.
You can quickly filter the webhooks list you need to manage with the help of configuration filtering fields. Filtering is possible by project name and repository name.
For the selected webhooks list you are able to apply the following actions:
Disable
Enable
Delete
Global settings
The Global Settings tab allows Bitbucket administrators to configure and customize the integration settings.
Here you can specify the list of parameters applied to the rest configuration levels located in Project Settings and Repository settings.
Below you can find a short definition of each parameter:
Parameter | Definition |
---|---|
| enables allowing multiple configurations per level This setting permits to have multiple configurations on the project and repository levels. Global configuration can be only 1. |
| determines whether the server URL should be appended to the target URL when sending webhook requests. It can be useful when the target system requires the server URL as part of the request. |
| enables the app to scan repositories for build status information. |
|
Available since 3.12 controls whether the app should disable a configuration if the associated project or repository in Bitbucket is moved or deleted. Not valid configurations are marked in yellow and shown only at the global level so that the global admin can amend or delete them. In the older versions, you may see |
| allows global-level rules to be executed independently (or on top) of the lower-level rules (e.g., repository or project level rules). If this setting is disabled the rules are combined into 1 rule for a particular event. But if this setting is enabled, it may cause double notifications if the rules on different levels are configured to override some settings and notify the same 3rd party system. |
| determines whether project level rules should be executed independently of repository level rules. These two parameters Repo or project admins set up their own configurations. Alternatively, by default, the rules are merged for each repository. |
| a list of allowed projects, only repositories within these projects will be considered for webhook execution. |
| a list of forbidden projects, repositories within these projects will be excluded from webhook execution. |
| repository writers to use REST APIs to manage configurations. |
| repository writers are allowed to use REST APIs to manage configurations. |
| disables the use of the old REST API for webhook execution. |
| the timeout duration for webhook requests; if the target URL doesn't respond within the specified time, the request will be considered as timed out. The default value is 30 sec. |
| the number of times the app should retry failed webhook requests before giving up |
| the base URL of your Bitbucket server or cloud instance |
Query string parameters support
How to use query string parameters
Maintenance
The Maintenance tab in the global configurations serves for managing and maintaining the webhook configurations ensuring their reliability.
Below you can find a short definition of each parameter:
Parameter | Definition |
---|---|
| export the current webhook configurations to a file. It is useful for creating backups or for migrating configurations to another instance of the app or Bitbucket server. |
| import webhook configurations from a previously exported file. It enables easy restoration of configurations or migration to a new instance of the app or Bitbucket server. |
| this parameter displays the result of the migration process when importing configurations. It helps you identify any issues or errors encountered during the migration and allows for troubleshooting if needed. |
Duplications
This section allows you to located and identify duplicated configurations. You can filter by Project & Repository
Rerun data migration
There is a Danger zone in the Maintenance tab, under the Database option, where you can delete all
existing configurations and rerun migration
from older (free) versions.
We recommend backup all data first.
Debugging and troubleshooting
Please follow these how-to articles:
How to set up Azure DevOps Pipeline triggering from Bitbucket Server?
How to integrate Bitbucket Server with Jenkins Pipelines?
How to enable notifications from Bitbucket in Microsoft Teams?
How to choose an authentication type?
How to use Mutual TLS for Jenkins and Bitbucket integration?
How to fix RepositoryMovedException error?
Updated: