QuickBuild integrates with Bitbucket server via the Bitbucket server repository. This repository has all features of a normal [Git repository|Working with Git], but add the ability to build against open pull requests, and update pull request status based on build result.
h2. Build against pull requests
To build against pull requests, define a Bitbucket server repository like below:
!repository.png!
In repository definition, tick the _build open pull requests_ option like below:
!pull_requests.png!
Upon triggering of configuration using such repository, QuickBuild will first find all open pull requests at Bitbucket server side and then fire separate build request(s) for each open pull request to check changes against that pull request, and build that pull request if necessary. So if there are many open pull requests, many build requests will be fired. So it is best practice to enable [concurrent build|Build Concurrency and Deadlock] to speed up verification of multiple pull requests.
As demonstrated below, each finished build will display associated pull request as branch information and changes of the build will be calculated against previous build with the same pull request branch.
!branch.png!
Upon manual triggering of such configuration, all matched pull requests will be built even if they've not being updated, just like what QuickBuild behaves when trigger configurations using normal repositories. However if you schedule the configuration and set build condition to _If changes found in referenced repositories_ (or something similar), QuickBuild will only build against new/updated pull requests.
h2. Update pull request status at Bitbucket server side based on build status
QuickBuild will update pull request status automatically to reflect build status when build is started/finished, as demonstrated below:
!build_status.png!
h2. BitBucket Webhook Integration
QuickBuild can trigger builds via BitBucket webhooks since 9.0.
h3. Config BitBucket
To enable the webhook, first you need go to BitBucket server webhook settings page to configure the QuickBuild side related information:
!bitbucket-settings.png!
Here, the URL for QuickBuild is in below format:
{code}
http://your-qb-server:8810/rest/webhook/bitbucket/{configurationId}
{code}
h3. Config QuickBuild
h4. Add anonymous group
As the webhook is triggered without authentication, anonymous group should be added and it should have the permission to use RESTful API.
h4. Add webhook settings
To add integration at QuickBuild side, please go to configuration settings page and then choose Webhook -> BitBucket from right side menu:
!webhook-menu.png!
Then, you can add the settings:
* *Trigger User* the user to trigger the build
* *Webhook Secret* the secret should be the same as what you defined in BitBucket
* *Trigger Condition* the trigger condition in Groovy scripts, when the result is true, build will be triggered, otherwise, the build will not be triggered.
* *Trigger Events* the events which are allowed to trigger the build, by default, only push event (_repo:refs_changed_) can trigger the build.
!bitbucket-webhook-settings.png!
h4. Event Payload
For detailed event payload please refer to below page:
https://confluence.atlassian.com/bitbucketserver/event-payload-938025882.html
You can use the payload data in the script. For example, in "Trigger Condition", you can use payload data via _delivery_ object, for example:
{code}
if ("pr:merged".equals(event)) {
return delivery.actor.name == "robin";
} else {
return false;
}
{code}
You can define *Trigger Build Variables* in the webhook settings, and then use those variables in configuration settings just like other variables. When define the variables, script is also supported, so the payload data can also be used via _delivery_ object, for example:
{code}
if (event.startsWith("pr:")) {
return delivery.pullRequest.fromRef.id;
} else {
return "master";
}
{code}
h4. Configure QuickBuild repository
You can specify the ref or commit like below so QuickBuild can build the pull request or specified commit:
1. add a variable in BitBucket webhook definition:
!bitbucket-webhook.png!
2. use the variable in BitBucket repository definition:
!bitbucket-repo.png!
h2. Build against pull requests
To build against pull requests, define a Bitbucket server repository like below:
!repository.png!
In repository definition, tick the _build open pull requests_ option like below:
!pull_requests.png!
Upon triggering of configuration using such repository, QuickBuild will first find all open pull requests at Bitbucket server side and then fire separate build request(s) for each open pull request to check changes against that pull request, and build that pull request if necessary. So if there are many open pull requests, many build requests will be fired. So it is best practice to enable [concurrent build|Build Concurrency and Deadlock] to speed up verification of multiple pull requests.
As demonstrated below, each finished build will display associated pull request as branch information and changes of the build will be calculated against previous build with the same pull request branch.
!branch.png!
Upon manual triggering of such configuration, all matched pull requests will be built even if they've not being updated, just like what QuickBuild behaves when trigger configurations using normal repositories. However if you schedule the configuration and set build condition to _If changes found in referenced repositories_ (or something similar), QuickBuild will only build against new/updated pull requests.
h2. Update pull request status at Bitbucket server side based on build status
QuickBuild will update pull request status automatically to reflect build status when build is started/finished, as demonstrated below:
!build_status.png!
h2. BitBucket Webhook Integration
QuickBuild can trigger builds via BitBucket webhooks since 9.0.
h3. Config BitBucket
To enable the webhook, first you need go to BitBucket server webhook settings page to configure the QuickBuild side related information:
!bitbucket-settings.png!
Here, the URL for QuickBuild is in below format:
{code}
http://your-qb-server:8810/rest/webhook/bitbucket/{configurationId}
{code}
h3. Config QuickBuild
h4. Add anonymous group
As the webhook is triggered without authentication, anonymous group should be added and it should have the permission to use RESTful API.
h4. Add webhook settings
To add integration at QuickBuild side, please go to configuration settings page and then choose Webhook -> BitBucket from right side menu:
!webhook-menu.png!
Then, you can add the settings:
* *Trigger User* the user to trigger the build
* *Webhook Secret* the secret should be the same as what you defined in BitBucket
* *Trigger Condition* the trigger condition in Groovy scripts, when the result is true, build will be triggered, otherwise, the build will not be triggered.
* *Trigger Events* the events which are allowed to trigger the build, by default, only push event (_repo:refs_changed_) can trigger the build.
!bitbucket-webhook-settings.png!
h4. Event Payload
For detailed event payload please refer to below page:
https://confluence.atlassian.com/bitbucketserver/event-payload-938025882.html
You can use the payload data in the script. For example, in "Trigger Condition", you can use payload data via _delivery_ object, for example:
{code}
if ("pr:merged".equals(event)) {
return delivery.actor.name == "robin";
} else {
return false;
}
{code}
You can define *Trigger Build Variables* in the webhook settings, and then use those variables in configuration settings just like other variables. When define the variables, script is also supported, so the payload data can also be used via _delivery_ object, for example:
{code}
if (event.startsWith("pr:")) {
return delivery.pullRequest.fromRef.id;
} else {
return "master";
}
{code}
h4. Configure QuickBuild repository
You can specify the ref or commit like below so QuickBuild can build the pull request or specified commit:
1. add a variable in BitBucket webhook definition:
!bitbucket-webhook.png!
2. use the variable in BitBucket repository definition:
!bitbucket-repo.png!