Bitbucket Datacenter/Server

Spacelift supports using an on-premises Bitbucket installation as the source of code for your stacks and modules. You can set up multiple Space-level and one default Bitbucket Data Center integration per account.

Setting up the integration

Creating the integration

In order to set up the integration from the Spacelift side, please navigate to the Source code page of Spacelift, click on the Set up integration button in the top right corner and choose Bitbucket Data Center

This should open a form like this one:

Explanation of the fields:

• Integration name - the friendly name of the integration. The name cannot be changed after the integration is created. That is because the Spacelift webhook endpoints are generated based on the integration name.
• Integration type - either default or Space-specific. The default integration is available to all stacks and modules. There can be only one default integration per VCS provider. Space-level integrations however are only available to those stacks and modules that are in the same Space as the integration (or inherit permissions through a parent Space). For example if your integration is in ParentSpace and your stack is in ChildSpace with inheritance enabled, you'll be able to attach the integration to that stack. Refer to the Spaces documentation to learn more about Space access controls and inheritance.
• API host URL - the URL of your Bitbucket server.
• User facing host URL - friendly URL of your Bitbucket server. This is the URL that will be displayed in the Spacelift UI. Typically, this is the same as the API host URL unless you are using VCS Agents: in that case, the API host URL will look like private://vcs-agent-pool-name, but the User facing host URL can look more friendly (for example https://vcs-agent-pool.mycompany.com) since it isn't actually being used by Spacelift.
• Username - the user name that Spacelift will use to access your Bitbucket.
• Access token - the access token that Spacelift will use to access your Bitbucket. See below for more details.
• Labels - a set of labels to help you organize integrations.
• Description - a markdown-formatted free-form text field that can be used to describe the integration.

Let's collect these details.

Creating an access token

In order to use the integration, you need a user account for Spacelift to use, and you need to generate an access token for that account. The user account requires the following access:

• Read access to any projects Spacelift needs to be able to access.
• Read access to the repositories within those projects that Spacelift should have access to.

Once you have a user account created, login as that user and go to Manage account -> Personal access tokens -> create. There, you will need to give your new access token a name and give it read access to repositories:

This will give you an access token which you can put into the Access token field in the integration configuration.

Saving the integration

Once you have your access token, enter it into Spacelift. At this point all the fields should be filled out:

You can now save the integration.

Configuring webhooks

In order for Spacelift to be notified of any changes made in your repositories, you need to setup webhooks in Bitbucket Data Center. You can find your webhook endpoint and webhook secret after clicking the 3 dots next to the integration name on the Source code page, and then clicking See details.

Note

Space-level integrations will be listed to users with read access to the integration Space. Integration details however contain sensitive information (such as webhook secret) so they are only visible to those with admin access. On the other hand, default integrations are visible to all users of the account, but only root Space admins can see the details of them.

For each repository you want to use with Spacelift, you need to go into its Repository settings -> Webhooks -> Create webhook, and configure the webhooks accordingly, by activating the following events:

• Repository > Push
• Pull Request > Opened
• Pull Request > Source branch updated
• Pull Request > Modified
• Pull Request > Approved
• Pull Request > Unapproved
• Pull Request > Merged
• Pull Request > Comment added

It should look something like this:

Warning

Don't forget to enter a secret when configuring your webhook. Bitbucket will allow you to create your webhook with no secret specified, but any webhook requests to Spacelift will fail without one configured.

Using the integration

When creating a Stack, you will now be able to choose the Bitbucket Data Center provider and a repository inside of it:

Using Spacelift checks to protect branches

You can use commit statuses to protect your branches tracked by Spacelift stacks by ensuring that proposed runs succeed before merging their Pull Requests.

Aggregated checks

If you have multiple stacks tracking the same repository, you can enable the Aggregate VCS checks feature in the integration's settings. This will group all the checks from the same commit into a predefined set of checks, making it easier to see the overall status of the commit.

When the aggregated option is enabled, Spacelift will post the following checks:

• spacelift/tracked - groups all checks from tracked runs
• spacelift/proposed - groups all checks from proposed runs
• spacelift/modules - groups all checks from module runs

Here's how the summary looks like:

Deleting the Integration

If you no longer need the integration, you can delete it by clicking the 3 dots next to the integration name on the Source code page, and then clicking Delete. You need admin access to the integration Space to be able to delete it.

Warning

Please note that you can delete integrations while stacks are still using them. See the next section for more details.

Consequences

When a stack has a detached integration, it will no longer be able to receive webhooks from Bitbucket Data Center and you won't be able to trigger runs manually either.

You'll need to open the stack, go to the Settings tab and choose a new integration.

Tip

You can save a little time if you create the new integration with the exact same name as the old one. This way, the webhook URL will remain the same and you won't have to update it in Bitbucket Data Center. You will still need to update the webhook secret though.