Global Configurations for Bitbucket admins

INCOMING WEBHOOK URL

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:

• POST;

• PUT;

• GET.

Skip URL Validation

by enabling this parameter the app will allow you to use URLs that may not conform to the standard validation rules

Enable Authentication

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:

• Authentication type - the type of authentication to be used when sending requests to the webhook URL: Basic, Bearer or Kerberos authentication;

Kerberos authentication is available since 3.22.12

• depending on type you choose you have to specify authentication details, such as, Username, Password or Token.

Enable Mutual TLS

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:

• Path to Key Store - contains the private key and the associated certificate used for Mutual TLS authentication.

• Path to Trust Store - contains trusted certificates used to verify the authenticity of other parties during Mutual TLS authentication.

• Key Store Password - the password required to access the Key Store file.

• Trust Store Password - password needed to access the Trust Store file.

Skip SSL Certificate Validation

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.

Payload type

allows you to specify which payload type should be sent.

Supports:

• Jenkins

• Azure DevOps

• Microsoft Teams

• Bitbucket (native format)

• GitHub

The Azure DevOps pipeline that should be triggered when the webhook event occurs. By enabling this option additionality you have to specify folowing parameters:

• Azure source - specifies where the target pipeline is located:

  • Cloud (URL pattern: https://dev.azure.com/{ORG_NAME}/{PROJECT_NAME}/_build?definitionId={PIPELINE_ID};

  • Server (URL pattern: https://yoursever/{COLLECTION}/{PROJECT_NAME}/_build?definitionId={DEFINITION_ID}

• Personal Access Token - the personal access token (PAT) used for authentication with Azure DevOps. Instruction on how to create here. The PAT should have appropriate permissions to trigger pipelines in the specified Azure DevOps project or organization: Scopes → Custom defined → Build → Read.

• Target Azure DevOps Branch - the branch in the Azure DevOps repository where the pipeline to be triggered is located.

• Parameters to send - additional parameters or variables that need to be passed to the Azure DevOps pipeline when triggering it.

To trigger GitHub workflow use the following parameters,

• the URL should have the following format https://api.github.com/repos/{REPO_OWNER}/{REPO_NAME_SLUG}/actions/workflows/{workflow.yml_FILE}/dispatches

• The payload to send contains key value set of parameters your workflow expects.

• Example of the payload

{"ref": "master", "inputs":{"eventType": "{eventType}","projectKey": "{projectKey}", "repositorySlug": "{repositorySlug}","branch": "{branch}"}}

Find more details on GitHub workflow integrations with Bitbucket here

Trigger GitHub workflows

Repository (Push) events

allows you to specify the type of events that should trigger the webhook

Include branches

the comma-separated list of Bitbucket branch regular expressions that should be considered when filtering events.

For instance, release/*, tag/*, etc.

Exclude branches

the comma-separated list of Bitbucket branch regexes that should be ignored.

Pull request events

allows you to specify the type of events that should trigger the webhook

Include 'From' branches, Included 'To' branches

the comma-separated list of Bitbucket branch regexes that should be included

Excluded 'From' branches, Excluded 'To' branches

the comma-separated list of Bitbucket branch regexes that should be ignored.

Excluded users

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, jenkins-user.

File path pattern

comma-separated list of file paths, only commits on these file paths will trigger the webhook.

For example, src/java/.*/src/main/resources/.*properties will trigger events only for the changes in the properties files.

Repository pattern

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, .*-Jenkins

Skip CI

skip triggering events for commits/pull requests that include the [skip ci] or [ci skip] keywords in their title or description.

Skip Forked repositories

skip the events that occur in forked repositories.

Include projects

comma-separated list of Bitbucket project keys that will trigger this event.

Exclude projects

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

Notification name

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.

Enable rule configuration

Disable to prevent this ruleset being active

Multiple configurations

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.

Append "server_url"

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.

Enable repositories scan for build status

enables the app to scan repositories for build status information.

Handle project/repository moved/ deleted events

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 RepositoryMovedException. Follow this guide to delete/change older issues. But the best option here is to update to the latest version and fix the highlighted rule in the Global configuration.

Execute global level rules additionally to lower-level rules

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.

Execute project level rules additionally to repository level rules

determines whether project level rules should be executed independently of repository level rules.

These two parameters Execute global level rules additionally to lower-level rules and Execute project level rules additionally to repository level rules meant to be used when you want the app works independently on each level.

Repo or project admins set up their own configurations. Alternatively, by default, the rules are merged for each repository.

Allowed projects

a list of allowed projects, only repositories within these projects will be considered for webhook execution.

Forbidden projects

a list of forbidden projects, repositories within these projects will be excluded from webhook execution.

Modification permit for writers

repository writers to use REST APIs to manage configurations.

Modification permit for readers

repository writers are allowed to use REST APIs to manage configurations.

Disable Old Rest API

disables the use of the old REST API for webhook execution.

Request timeout

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.

Request retry count

the number of times the app should retry failed webhook requests before giving up

Bitbucket base URL

the base URL of your Bitbucket server or cloud instance

Export configurations

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 configurations

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.

I want to see all configurations migration result

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.