This changelog is the source of truth for all changes to the Bitbucket API and Bitbucket Connect API that affect people using Bitbucket Cloud and developing Bitbucket Cloud apps.
To ask any questions related to Bitbucket Cloud development please visit the Bitbucket Cloud developer community.
Dynamic Pipelines for Bitbucket Cloud are now generally available.
Dynamic Pipelines allow you to utilise Forge functions to augment and modify CI/CD workflows at runtime, implementing sophisticated dynamic logic that will enable unparalleled levels of CI/CD control.
For more info, check out the announcement post.
Custom merge checks are now generally available in Bitbucket Cloud. For full details on all the changes coming as part of this release, refer to our deep-dive blog post.
This release includes the following changes:
Repository Admins:
Custom merge checks can now be configured as either “recommended” or “required”.
“Recommended” checks will provide feedback to the PR author if failing, but will not block the merge.
“Required” checks will block the PR if failing.
As per existing classic merge checks, setting custom merge checks as “Required” is only available in premium workspaces.
Pull request reviewers/authors:
Classic merge check and custom merge check results have been consolidated into a single UI Element on the Pull Request screen.
The UI behaviour of classic merge checks has been updated to be consistent with the design of custom merge checks.
Failing “recommended” merge checks will be visible on the check result sidebar card with a unique visual indicator.
Custom merge checks that run “on-merge” have been more clearly distinguished from conventional “pre-merge” checks on the checks result sidebar card.
Introducing new REST API endpoints to facilitate the management of pull request tasks. For further details, please refer to the documentation:
The progressive rollout of data security policy events has been completed. Data security policy events are generated when installed apps' access to certain data within Confluence, Jira, Jira Service Management, or Jira Software has been blocked by an administrative policy with an App access rule. You can now subscribe to these events.
Being a new capability however, we are scaling up our processing of these data security policy events over the next few months. In the meantime we have set a upper limit of 50,000 objects. This means that if a customer activates or updates a data security policy that affects more than 50,000 objects, you will receive the first 50k objects in the events and the rest would be omitted.
We intend to raise these limits and will advise once we have reached our final threshold— and have determined our final hard limits.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party app access to certain content in select spaces.
If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.
We have started the rollout of data residency for Forge hosted storage, where data will be moving to the same location as the host product. To ensure a smooth rollout, we will be rolling out the feature to customers gradually over the next month.
Once the rollout is complete, Forge hosted storage data will be stored in the same location as the host product for all new and existing Forge apps, for all current and future Atlassian-supported locations. We will let you know when the rollout is complete.
Action Required
Last month, we outlined some actions required to prepare for this rollout (see changelog for more information). If you haven’t done so yet, we recommend:
redeploying any app that uses Forge-hosted storage
updating the manifest for any apps that use remotes or external permissions (for details about how to do this, see our documentation).
At the end of the staged rollout, we also recommend updating the Privacy & Security tab for any app that exclusively uses Forge hosted storage for in-scope End User Data, to indicate that your app supports data residency. You should also define in your app documentation what data is in-scope and out-of-scope. This way you can let customers know about your app’s support for data residency. We will let you know when to make this update.
Data residency for Forge-hosted storage is the latest milestone on our shared mission to offer enterprise-ready apps to customers in the cloud. With data residency available for Forge-hosted storage, meeting a key customer trust requirement will be easier than ever.
It’s important to note that, as we shared last November, when data residency reaches beta for Forge-hosted storage, app data stored in Forge-hosted storage will automatically inherit data residency in all current and future regions supported by the host product. This will not be reversible.
We have updated the ‘Merge’ button on the pull request page. Now, when there are failing pre-merge checks preventing a pull request from being merged, the ‘Merge’ button will be yellow with a warning icon.
As mentioned in the previous announcement, if your Forge app has the bitbucket:mergeCheck module, it needs to include the read:pullrequest:bitbucket scope.
This is now enforced at runtime. If you deploy an app containing bitbucket:mergeCheck module without the read:pullrequest:bitbucket scope, the app’s mergeCheck functions will fail to be invoked.
Make sure that you:
Update your app manifest.
Redeploy via forge deploy.
Update the app installations via forge install --upgrade.
When creating custom merge checks for Bitbucket Cloud, you can now use a remote endpoint in place of a hosted function.
You can optionally configure your https://developer.atlassian.com/platform/forge/manifest-reference/endpoint/ to receive an appSystemToken which can be used to make API requests back to Bitbucket APIs and Forge storage.
See https://developer.atlassian.com/platform/forge/forge-remote-overview/#remote-delivery-of-product-events--lifecycle-events-and-scheduled-triggers for more information.
Forge apps using the bitbucket:mergeCheck module will now require the read:pullrequest:bitbucket scope in their manifest.
When deploying an app, if the read:pullrequest:bitbucket scope is not in the manifest, the forge deploy command will fail.
In a few weeks, the read:pullrequest:bitbucket scope will be enforced at runtime. This means that, if the scope is not present in the deployed and installed version of an app, the app checks function will fail to be invoked.
In preparation for this change, we recommend:
deploying the app with the additional scope to each environment, production included
install the deployed version of the app via forge install --upgrade to every workspace for each environment
apps distributed to customers will need to be upgraded by following the steps here: https://developer.atlassian.com/platform/forge/distribute-your-apps/#share-an-app-update
Another changelog will be posted when the scope is enforced at runtime.
If you have any questions, please add a comment to the community post.
As part of our preview release of Forge UI Kit 2, we're releasing a new major version of @forge/react with 37 updated components.
From version 10 onwards, existing component APIs are now updated, and a range of new components are now supported in UI Kit 2. For more details, see our documentation here.
The new version is supported within the following products:
Confluence
Jira
Bitbucket
Compass
Updating to the latest version may contain breaking changes for existing UI Kit 2 apps, as all existing component APIs have been updated. The breaking changes are only applicable if you choose to upgrade your UI Kit 2 apps.
Our component documentation contains more details on the props each component will now take.
To update your UI Kit 2 app to the latest version, in the terminal from your project directory, run the following command:
npm install --save @forge/react@latest
If you’re still using older versions of UI kit, such as the previous version of UI Kit 2 (@forge/react version 9) and UI Kit 1, you can find their corresponding documentation here.
We added a new on-reviewer-status-changed trigger type for Bitbucket Custom Merge Checks (currently available under EAP). You can use this trigger type to invoke your check whenever a reviewer status changes. See the Custom merge check (EAP) - Triggers page for details.
Bitbucket integration with Forge is now fully supported, with a minimum 6-month deprecation period for breaking changes. All Bitbucket modules are now released under GA as well (except for Custom merge checks, which is still available only under EAP right now).
For more information on Forge release stages, see: https://developer.atlassian.com/platform/forge/whats-coming/
We've published a new package, @forge/bitbucket, to aid the development of Forge apps on Bitbucket.
The package provides helper functions that developers may frequently use when creating their Forge apps. See the package documentation for more information.
bitbucket:mergeCheck module is now available. You can use this module to build custom merge checks for Bitbucket Cloud. Upgrade your Forge CLI version to 6.22.1 to access the template for this module. See the Custom merge check (EAP) page for technical details. Read more about this functionality and why we've introduced it in our blog: [beta] Custom Merge Checks in Bitbucket Cloud.
bitbucket:workspaceSettingsMenuPage module is now available. You can use this module to build a custom workspace settings page. Upgrade your forge CLI to 6.22.0 to access the template for this module. See the Workspace settings menu page for details.
Rate this page: