Bitbucket

4 minute readExtensibilityDeveloper productivity

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.

Supported versions

The plugin has been tested with the following versions:

  • Bitbucket Cloud API v2.0

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 Administration Plugins 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

ParameterDescription

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

ParameterDescription

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

ParameterDescription

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.

Output parameters

ParameterDescription

id

Pull request ID

link

Link to the created pull request

Post commit status

This procedure posts a status of the build associated with the commit.

Post commit status parameters

ParameterDescription

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 https://ci.example.com/builds/{repository.full_name} which Bitbucket will turn into https://ci.example.com/builds/the-user/the-repository at render time.

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$'.

Release notes

EC-Bitbucket 1.2.0

  • Added typed exceptions to the webhook script.

EC-Bitbucket 1.1.0

  • Enabled support for procedure "Approve pull request".

  • Enabled support for procedure "Create pull request".

  • Enabled support for procedure "Post commit status".

EC-Bitbucket 1.0.2

  • Upgraded third-party dependencies to address security issues.

EC-Bitbucket 1.0.1

  • Missing event handling checkbox for trigger is now treated as disabled

EC-Bitbucket 1.0.0

  • Added Webhook event processing support for the following events - Push - Pull Request