Build, test, and deploy with unlimited private or public space with Bitbucket®. One tool for all your professional needs from code to deployment.
This plugin adds support for Bitbucket webhooks. Only the Bitbucket Cloud is supported. Supported event types are: push
and pull_request
.
Plugin version 1.2.0.2021120826
Revised on December 29, 2021
Overview
Integration with Bitbucket REST v2 API to create, manage and manipulate git-repositories.
The difference between Git and other services around Git
Git
Provides the main functionality for managing git-repositories and their data, which can be deployed anywhere.
GitHub
Provides additional GitHub REST API functionality.
Bitbucket
Provides additional Bitbucket REST v2 API functionality.
Plugin configurations
Plugin configurations are sets of parameters that apply across some or all of the plugin procedures. They reduce repetition of common values, create predefined parameter sets for end users, and securely store credentials where needed. Each configuration is given a unique name that is entered in designated parameters on procedures that use them.
Creating plugin configurations
To create plugin configurations in CloudBees CD, do these steps:
-
Go to
to open the Plugin Manager. -
Find the EC-Bitbucket-1.2.0.2021120826 row.
-
Click Configure to open the Configurations page.
-
Click Create Configuration as per the description of parameters below.
Configuration procedure parameters
Parameter | Description |
---|---|
Configuration Name | Unique name for the configuration |
Description | Configuration description |
Bitbucket REST v2 API | |
Auth Scheme | Authorization scheme for the third-party connection. |
Check Connection? | If checked, the connection endpoint and credentials entered as part of the configuration will be tested. If this option is checked, configuration will not be saved if the test fails. |
Debug Level | This option sets debug level for logs. If info is selected, only summary information will be shown, for debug, there will be some debug information and for trace the whole requests and responses will be shown. |
Plugin procedures
Approve pull request
This procedure approves pull request with the credentials of the service account configured for the plugin.
Approve pull request parameters
Parameter | Description |
---|---|
Configuration Name | Previously defined configuration for the plugin |
Workspace | This can either be the workspace ID (slug) or the workspace UUID surrounded by curly-braces, for example: {workspace UUID}. |
Repository slug | This can either be the repository slug or the UUID of the repository, surrounded by curly-braces, for example: {repository UUID}. |
Pull request ID | Pull request ID, a number. |
Create pull request
This procedure creates a pull request
Create pull request parameters
Parameter | Description |
---|---|
Configuration Name | Previously defined configuration for the plugin |
Workspace | This can either be the workspace ID (slug) or the workspace UUID surrounded by curly-braces, for example: {workspace UUID}. |
Repository slug | This can either be the repository slug or the UUID of the repository, surrounded by curly-braces, for example: {repository UUID}. |
Source | Source branch name, e.g. my-feature-branch |
Destination | Destination branch name, defaults to the repository.mainbranch. |
Title | Pull request title |
Description | Description for the pull request. |
Reviewers | Either UUIDs of the reviewers, separated by a newline or their usernames. If the username is provided, the user must exist in the workspace. |
Close source branch | Specifies if the source branch should be closed upon merge. |
Post commit status
This procedure posts a status of the build associated with the commit.
Post commit status parameters
Parameter | Description |
---|---|
Configuration Name | Previously defined configuration for the plugin |
Workspace | This can either be the workspace ID (slug) or the workspace UUID surrounded by curly-braces, for example: {workspace UUID}. |
Repository slug | This can either be the repository slug or the UUID of the repository, surrounded by curly-braces, for example: {repository UUID}. |
Commit ID | ID (SHA1) of the commit to post status to, e.g. bdfd735733a798823193e5997576b50aba1033e6 |
Key | An identifier for the status that’s unique to its type. If not provided, TEST key will be used. |
URL | A URL linking back to the vendor or build system, for providing more information about whatever process produced this status. Accepts context variables repository and commit that Bitbucket will evaluate at runtime whenever at runtime. For example, one could use |
Description | A description of the build (e.g. "Unit tests in CloudBees CD") |
Mimic runtime status | If selected, the GH status will be posted according to the status of the current CD runtime. |
Status | Provides some indication of the status of this commit |
Webhook Support
The new Trigger model was introduced in the CloudBees CD version 10.1.
EC-Bitbucket adds possibility to automate launch of the runtimes CloudBees CD for: - Push events - Pull Requests
Please refer to the CloudBees CD documentation for the setup tutorial.
Runtime values according to the event type
When the procedure/pipeline/etc. is started by a webhook event, additional properties will be available under the '/myWebhook' property sheet. This properties are parsed from the event payload which itself is saved under the /my(Job|PipelineRuntime|etc.)/webhookData. The list of parsed properties depends on the event type. In some cases the event payload may not contain the data for a property and it will be missing.
Push event
The runtime will contain the following properties:
-
branch
-
repository
-
eventType
-
commitId
-
commitMessage
-
commitAuthorName
-
commitAuthorEmail
-
webhookData/branch
Pull Request event
The runtime will contain the following properties:
-
branch
-
repository
-
eventType
-
commitId
-
commitAuthorName
-
webhookData/number
-
webhookData/title
-
webhookData/body
-
webhookData/state
-
webhookData/author
-
webhookData/url
Notes: The branch names in the "Include Branches" and "Exclude Branches" are patterns, so the value 'master' will correspond to any branch that contains 'master', e.g. 'test-*master*ing-data'. If you want to specify the exact branch you should use the line start and line end symbols '^master$'.