Bitbucket: Recent Episodes
None
By popular demand, we are happy to introduce several new strategies for syncing and merging branches in Bitbucket Cloud. Our goal is to provide you the full functionality of rebase and merge within the Bitbucket UI to help you manage your Git history according to your team's preferences.
These new options have been among our most highly voted feature requests. In brief, here's what we've added:
- A rebase sync option for when your pull request has fallen behind the target branch.
- New options when it's time to merge your PR: rebase + merge, rebase + fast forward, and squash (fast forward only).
Sync via rebaseUntil today, when a source branch is missing commits from the target branch, Bitbucket has only offered the option to merge the target branch back into the source branch by creating a merge commit. Merge commits add a new commit on your source branch history, which can make the Git history noisy and difficult to track.
For teams that prefer a "cleaner" commit history, the new option to rebase sync (previously possible only from the command line) enables you to rewrite the commit history with the latest updates from the source branch.
To do a rebase, look for the message on your pull request that a sync is available:
After selecting "Sync now", you can choose between a merge commit or a rebase:
Why would you choose to sync via rebase versus merge commit? It's a matter of your team (or personal) preference about maintaining branch history. To learn more about rebasing, check out Atlassian's Git tutorial.
Expanded merge strategiesMerge strategies define how the commit history appears when you merge a completed pull request into the target branch. Historically, Bitbucket Cloud has supported merging via merge commit, squash, and fast-forward. Today we've added three additional strategies: rebase + merge, rebase + fast forward, and squash (fast forward only).
You'll find the new merge strategy options in the same place as the existing ones – in the pull request merge dialog:
Admins can set the default strategy for pull requests in Project settings or Repository settings > Merge strategies.
Bitbucket's documentation on merging a pull request has details on how all these strategies work.
We hear you If you have any feedback – good or bad – about these new merge & sync options, please head to the Bitbucket help menu > Give feedback to share your thoughts with us.
PS: Coming very soon to a pull request near you: dark mode!
The post Git, your way: Expanded strategies for branch sync & merge appeared first on Bitbucket.
We recently announced our deep commitment to keeping your code secure in the cloud. With that, we are excited to announce a setting that gives admins increased controls over forking outside their Bitbucket workspace.
Currently, a user can fork content from a repository into a workspace outside of your private workspace. While there are some use cases where this is useful, we also understand why a lot of you would like to prevent forks outside your workspace to better protect your code. With the launch of this setting, all workspace admins will now be able to configure their workspaces to ensure no code is forked out.
How it worksTo enable this setting, go to Workspace settings and select the Do not allow forking of private repositories to other workspaces setting.
When this feature is enabled, private repositories cannot be forked outside of the workspace. Note that this does not include content inside a public repository, as public repositories are used to collaborate with users outside your organization.
Benefits of using this featureBy preventing forks outside your workspace, you can expect:
- Increased Control: Workspace admins gain more control over their workspaces. You can decide whether or not you want to allow content from a private repository to be forked outside the workspace.
- Enhanced Privacy: By ensuring that users cannot fork outside of your managed workspace, you can prevent accidental exposure of sensitive data. Users will not be able to fork private repositories outside of your workspace.
- Better Tracing: Changes to forked content is tracked in audit logs which is available via Atlassian Guard.
What’s next?We’re continuing to invest in improving the privacy and security of workspaces and the projects and repositories within them. You can read more about all the features we've shipped in the privacy and security space in this Bitbucket blog.
The post Introducing increased control over forking in Bitbucket Cloud appeared first on Bitbucket.
We’re excited to announce a significant improvement to our API rate limits for Bitbucket Cloud. This new feature will provide more flexibility and capacity for our Standard and Premium customers, especially those with larger teams.
What’s Changing?1. Scaled Rate Limits: We’re introducing scaled rate limits to a group of endpoints that can handle the increased load from the API requests. This group of API endpoints is in a collective known as the api resource group, which covers most /2.0/repositories/* endpoints. This scaling applies to requests made via Access Tokens and Forge asApp API requests.
2. New Rate Limit Headers: To help you manage your API usage, we’re adding new response headers for affected endpoints when accessed via Access Tokens or Forge.
How Do Scaled Rate Limits Work?The new scaled rate limits are based on your workspace’s paid user count. Here’s what you need to know:
- The base rate limit remains 1000 requests per hour (RPH) for workspaces with up to 100 seats.
- For workspaces with more than 100 seats, you’ll get an additional 10 RPH for each seat above 100.
- The maximum rate limit is capped at 10,000 RPH.
For example, if your workspace has 250 seats, your new rate limit would be:
1000 RPH (base) + (150 additional seats * 10 RPH) = 2500 RPH
Who Benefits?This change benefits our Standard and Premium plan customers with more than 100 users. Free plans, which are limited to 5 users, and paid plans with under 100 paid users will not see any changes to their rate limits.
New Rate Limit HeadersTo help you monitor your API usage, we’ve introduced new response headers for the affected endpoints. These headers will provide real-time information about your current rate limit status, which helps you to optimize your API requests and avoid hitting any limits.
Requests made by Access Tokens or Forge to scaled endpoints will receive 3 new headers:
X-RateLimit-Limit: Represents the total number of requests permitted per hour. Note, this is not the number of remaining possible requests.X-RateLimit-Resource: Identifies the API endpoint resource group receiving increased rate limitsX-RateLimit-NearLimit: A boolean value indicating whether less than 20% of the requests remain
What’s Next?This change is already live for all Standard and Premium customers. You don’t need to take any action to benefit from these new limits – they’ll be applied automatically based on your workspace’s paid user count.
We’re excited to see how this change will empower our customers to build even more powerful integrations and workflows with Bitbucket Cloud. As always, we welcome your feedback and questions. Please don’t hesitate to reach out to our support team if you have any concerns and reach out to Atlassian Community to get help from our champions.
The post Introducing Scaled Rate Limits for Bitbucket Cloud API appeared first on Bitbucket.
In this blog, we walk through Atlassian's cloud security practices and the controls we give you inside Bitbucket to maintain enterprise-grade security, without the overhead of managing it internally.
Security is an essential part of Atlassian's offerings. We manage code and data for over 300,000 customers who serve hundreds of millions of users. To secure data at the scale we operate, we invest more in security than most individual organizations can.
Atlassian takes all necessary steps to protect and secure customer data from unauthorized access at the platform level. This includes data encryption, monitoring for security issues, performing regular backups and more. We also provide you with granular security controls within the product so you can configure security options per your internal policies.
Platform level security Bitbucket Cloud is hosted on the same, secure platform that hosts Jira, Confluence and your other Atlassian products. Here are the things that we do at the platform level to protect your data and manage any security risks across our systems and people.
- Our production systems are hosted on Amazon Web Services (AWS) and hosted across multiple availability zones for optimal performance and to ensure that a failure in any single data center does not affect the availability of our products or your data.
- All code and data is encrypted in transit using TLS 1.2+ with Perfect Forward Secrecy (PFS) and at rest with AES-256 encryption to protect from any unauthorized access.
- Backups are taken daily and are stored in multiple data centers within a particular AWS region in case of a specific data center failure. We perform quarterly testing of our backups to ensure that they function as intended. While we backup data for disaster recovery purposes, you can use a backup app such as Rewind to backup for recovery due to user errors.
- We have multiple endpoint protection solutions to protect against threats such as malware.
- We use role-based access control to ensure our staff only have the access appropriate to their job role. All user accounts are approved by management prior to having access to data, applications, infrastructure or network components.
For more details, learn more about Atlassian's security approach here.
Security settings that you can manageSince security requirements vary across regions and industries, we offer several security settings within Bitbucket Cloud that you can configure to ensure that your access levels meet your internal compliance needs.
- IP allowlisting:With IP allowlisting, users will only be able to interact (view, push, clone, etc.) with your code if they are accessing Bitbucket from an IP address that you have selected and know is secure. This helps prevent unwanted third parties from accessing your code even if they have acquired a team member's login credentials.
- Enforce 2FA: Another way of protecting against password leaks is by enforcing 2FA (two-step verification). This adds another layer of security by requiring that all Bitbucket users are required to use 2FA when accessing code.
- Disable public content: Bitbucket workspaces can contain both private repositories and public (open source) repositories. Public repositories are used to collaborate with users outside your organization while private repositories can only be accessed by users who are part of your workspace. You can disable users from creating public repositories within your workspace.
- Disable forking outside the workspace: By default, a user can fork code from a repository into a workspace outside of your private workspace. While there are some use cases where this helps, we also understand that you may want to prevent this to ensure that your code always stays within your private workspace. You can disable forking outside of your workspace.
- Support for self-hosted runners: If you have security requirements that require you to run your builds on-premises, you can configure your CI/CD pipelines to point to your own runners behind the firewall. We support on-premises runners across all major platforms.
- Audit logs: Bitbucket Cloud event logs are in Atlassian Guard so you can view them in one UI along with Jira and Confluence logs. Admins can track down changes in settings or permissions that affect compliance and security teams can use these logs to investigate incidents.
- Enforced signed commits (roadmap): By enforcing signed commits, you can authenticate the user who submitted the commit to ensure that it has not been tampered with. You’ll be able to set rules to reject unsigned commits to ensure that all code being merged to production has been submitted by an authenticated user.
Code security tools that you can use to protect your customersBeyond platform security and product security controls that we offer, our built-in CI/CD capabilities enable you to integrate code security tools into your code pipeline to ensure that your code is secure when it gets to your production systems.
Here are four things you can do to within your CI/CD pipeline to ensure that your code remains secure for your customers.
- Check for exposed secrets: Use out git-secrets pipe to automatically check all all code for any exposed user credentials. When any secret exposure is detected, your pipeline stops the deploy and alerts you.
- Scan for security vulnerabilities: Use a security scan pipe such as Snyk, SonarCloud or others to get alerted about security vulnerabilities before you ship
- Set workspace level merge checks (roadmap): Create a list of your merge check criteria and implement them at scale at the workspace level, so it applies to merges across all repositories and projects. For example, scanning for secrets and security vulnerabilities could be applied as a workspace level check that needs to pass before the merge is approved.
- Orchestrate security at scale with dynamic pipelines: With our dynamic pipelines feature, you can have governance on all pipelines running across your organization and ensure that the required security steps are being performed before code is deployed. If not, you can dynamically insert these checks into the pipeline. This is an additional layer of security beyond merge checks that can be used in the CI and/or CD pipeline.
More resources, questionsIf code security is a concern that is holding you back from moving forward with your migration to cloud, please reach out with your security questions via your Account Manager or open a support ticket (select 'migration support' from the dropdown). For more security resources, view our Trust Center for details on our practices.
If you're on an active Data Center license, you can sign up for a free cloud migration trial of the Bitbucket Premium plan – sign up here – and use our cloud migration app to help you move your code to the cloud.
The post Keeping your code secure in the cloud appeared first on Bitbucket.
As part of our strategy to build for scale, security, and performance, Bitbucket Cloud is continuing to deliver features that help enterprise teams operate at scale to build world-class software.
We've made a lot of progress this year with new features across code review and CI/CD. We've added AI functionality, added features to help you scale your CI/CD workflows, and integrated with Forge, our cloud app development platform, to help you build customizations into Bitbucket to meet your specific needs.
Migrating to cloud: If you're a Bitbucket Data Center customer looking to migrate to Bitbucket Cloud, sign up for a free trial of Bitbucket Cloud Premium. With Bitbucket Cloud (demo), you get a trusted, secure platform, with deep integrations to Atlassian tools and market-leading DevOps apps to help you connect your workflow from planning to production.
In this blog, we're sharing some of what we've recently shipped and what we're building.
Driving productivity with Atlassian IntelligenceCrafting clear, concise PR descriptions for complex changes can be time-consuming and frustrating. We know the struggle is real. That's why we launched AI generated pull request (PR) descriptions.
Atlassian Intelligence analyzes your code changes and commit messages to learn what changes were made and uses this information to generate a PR description that effectively captures the key aspects of your changes.
With our ChatGPT code review pipe, you can now configure AI code review from your CI/CD pipeline. When you include the pipe in your CI pipeline, ChatGPT will analyze your code changes and leave comments on suggested fixes. Make those changes and commit so your peer reviewers can complete the review faster.
- pipe: atlassian/bitbucket-chatgpt-codereview:0.1.3 variables: OPENAI_API_KEY: "<string>" BITBUCKET_ACCESS_TOKEN: "<string>" MODEL: "<string>" # ORGANIZATION: "<string>" # Optional # MESSAGE: "<string>" # Optional # FILES_TO_REVIEW: "<string>" # Optional # CHATGPT_COMPLETION_FILEPATH: "<string>" # Optional # CHATGPT_CLIENT_FILEPATH: "<string>" # Optional # CHATGPT_PROMPT_MAX_TOKENS: "<string>" # Optional # DEBUG: "<boolean>" # Optional
(roadmap) Rovo integration With Atlassian Rovo launching soon, we are working to integrate Bitbucket Cloud repos, commits and pull requests into Rovo's unified search. With unified search, you'll be able to search across Atlassian tools like Jira, Bitbucket, Confluence as well as third-party tools like Google docs in one UI.
Bitbucket Cloud will also be integrated into Rovo chat, a chat UI that you can interact with to ask questions about your code.
A much improved pull request user experienceThe pull request and code review workflow in Bitbucket is where your most critical work gets done to ensure that quality code gets merged into production. We've revamped the UI and added many new features to make it easier to review complex diffs more effectively.
With iterative review, when an author pushes a new commit based on your PR feedback, during your next review, you won't have to re-review the whole PR again – you can choose to review only what changed since your last review.
As your team and products grow, it becomes hard to track who has expertise in various areas of your code base. This makes it hard to identify who are best qualified to review code changes. Now you can set up a code owners file in your repository and define ownership for specific code files/paths, enabling Bitbucket to auto-assign reviewers automatically based on what files are being modified.
```
.bitbucket/CODEOWNERS# Default reviewers for files not matching patterns below alisha@example.com fred@example.com# Choose all members of a workspace group.js @workspace-slug/frontenders:all# Choose group members tagged on the fewest open PRs.py @workspace-slug/backenders:least_busy(2)# Choose randomly from a custom team (defined in teams.yaml).tf @teams/sre-leads:random(2)
``` To manage code quality at scale, you can now build your own custom merge checks and have it show up with our native merge checks inside Bitbucket. This means you can create your own code compliance rules, e.g. no merges on weekends, check for Snyk security scan, or anything else, and Bitbucket will automatically check for compliance before every merge. On a premium plan, you can also choose to enforce the check so a merge will fail when your check fails. This is useful when you have strict requirements.
(roadmap) To help you scale these custom checks, we're adding a global setting so admins can apply these checks at the workspace-level to manage code quality across all your projects and repositories.
More layers of securityBitbucket Cloud runs on the same Atlassian Cloud platform that powers Jira, Confluence and other Atlassian products. Customer trust is at the center of what we do and security is our top priority. We’re transparent with our security program so you can feel informed and safe using our products and services.
Beyond platform level security, we are continuing to add security controls into the product that you can configure based on your internal compliance requirements.
Enforce private workspaces
Currently, a private Bitbucket workspace can contain both public and private repositories. Public repositories are used to collaborate with users outside your organization while private repositories can only be accessed by users who are part of your workspace.
We’ve heard from many of your that due to security concerns, you want to be able to restrict your users from creating public repositories. With the launch of this feature, workspace admins on a Premium plan can now check a box to ensure that all projects and repositories created within your workspace are private. Users will not have the option to create public content. Learn more
(roadmap) Enforce signed commits
Signed commits add a layer of security to commits by authenticating the user who submitted it and ensuring that the commit has not been tampered with. By enforcing signed commits in Bitbucket, you'll also be able to set rules to reject unsigned commits to ensure that all code being merged to production has been submitted by an authenticated user. If you have compliance policies that require the use of signed commits, this will satisfy those requirements.
CI/CD built for scaleWe launched dynamic pipelines, which lets you use our Forge platform, to programmatically manage CI/CD pipelines at scale. You can build logic to dynamically generate pipeline yml based on the code context, or insert specific pipeline steps into all user generated pipelines to meet your compliance needs e.g. if a security scan is not part of the pipeline, it can be included dynamically during runtime. This lets you centrally manage CI/CD pipelines across your organization at scale.
We released our next-gen CI/CD runtime. With this launch, you can enable significantly larger instance sizes for your CI/CD workloads – giving your teams up to 8x more CPU and memory for their builds and 16x coming later this year.
We have a strong roadmap ahead.
(roadmap) The new runtime will act as the foundation for a range of powerful new future capabilities like ARM and multi-arch builds in cloud
(roadmap) You'll be able integrate with with third-party secret management tools such as Vault, so you can centrally manage your secrets outside of Bitbucket.
(roadmap) Steps will have their default maximum execution time extended significantly, supporting much larger builds and more complex CI/CD workflows.
(roadmap) Access detailed insights and data related to your automated test suites to optimize your tests. Understand what types of tests are failing and causing your builds to break. Use these insights to improve your overall test health and reduce your build failure rates.
(roadmap) There are several benefits to moving your CI/CD to the cloud. We have customers who want to move off of legacy on-prem CI/CD tools like Jenkins. We are building migration tooling to help you automate migrating from Jenkins to Bitbucket Pipelines.
New to Bitbucket Cloud?If you’re currently using Bitbucket Data Center and considering migrating to Bitbucket Cloud, here is a demo to that walks you through core functionality and you can build end to end developer workflows from planning to production on the Atlassian platform.
Migration resources: We have an Atlassian-supported free migration tool to help you move your code and metadata to Bitbucket Cloud, a migration planning guide, and if you have questions along the way, our support team is ready to help. Get started by signing up for a free extended trial of Bitbucket Cloud Premium.
The post What’s new & what’s coming to Bitbucket Cloud appeared first on Bitbucket.
New Pipelines RuntimeBack in June we announced the release of our new CI/CD runtime for Bitbucket Pipelines, bringing with in new capabilities for customers and providing up to 8x faster CI/CD builds. The release of our new CI/CD runtime enabled customers to access the new 4/8x sizes for their builds, providing up to 16 CPU cores and 32 GB of memory to each build.
Additionally, the new runtime also enables us to offer a range of additional benefits to users – most importantly being the ability to provided dedicated CPU cores to each build, rather than access to shared CPU pools. One of the biggest benefits this will have for customers is related to a change being made in how we allocate CPU and memory to 1/2x builds (especially for 2x) once they are also moved to the new runtime.
As mentioned in June, the existing 1/2x step sizes would remain on the old runtime until September 17th, 2024, at which point they will be migrated over to the new runtime as well.
New CPU & memory allocationPreviously, builds in Pipelines shared CPU resources, leading to discrepancies between perceived and actual available compute power. Tools within builds would see 4 cores but only have access to about 1.8 cores of real compute.
The new Pipelines runtime addresses these inconsistencies by moving to a more dedicated CPU allocation model. The main change is that 1x builds will now show 2 cores instead of 4, while 2x builds remain at 4 cores.
Important: We want to emphasise that this is NOT a reduction in compute for 1x steps. In fact, 2x steps will see a significant INCREASE in compute allocation. The move to a dedicated CPU model means each visible CPU will provide more actual compute power.
As a result, 1x steps will maintain similar compute levels, while 2x steps will have approximately double the CPU allocation compared to before, aligning with their 2x memory allocation compared to 1x steps.
Bringing 1/2x steps to the new runtimeAs mentioned back in June, the move to the new runtime also brought some changes, most importantly to IP addresses that Pipelines builds are served from that may impact customers that leverage IP Allow-listing.
On September 17th, 2024, we will be retiring the legacy Pipelines runtime for builds running on 1x and 2x sizes. Those step sizes will be automatically migrated to the new Pipelines runtime, as part of this process.
To be clear, 1x and 2x sizes are not being retired, they are simply being moved to the new Pipelines runtime.
As part of this deprecation:
- No changes are required in your Pipelines configuration.
- If you use IP allowlisting to control access to your internal networks from Pipelines, please update to the new IP address ranges for the new runtime as listed in the Pipelines documentation prior to September 17th.
For context, Atlassian has been running on this new runtime for it's internal CI/CD for an extensive period of time and has completed millions of builds with it, with no major incompatibility being experienced.
The post Migrating Pipelines 1/2x steps to our new CI/CD runtime appeared first on Bitbucket.
This new demo showcases core Bitbucket Cloud workflows across code review and CI/CD, and highlights some of the benefits of using Bitbucket Cloud with Jira, Jira Service Management, and Compass.
Even if you’ve been using Bitbucket for a while, this demo will show you a few things you may not have tried yet.
Or if you’re currently on Bitbucket Data Center and are considering migrating to cloud, this demo provides a good overview to share with your team.
What’s in the demo:
- How Bitbucket and Jira work together to keep teams in sync and reduce context switching.
- The pull request experience including AI functionality.
- Walks through our built-in CI/CD functionality and how you can build an end-to-end delivery workflow.
- How code is connected seamlessly across Atlassian tools, including Compass and Jira Service Management.
- …and we also touch on some ways you can use Forge, our app development platform, to customize your instance to enforce code quality and manage CI/CD at scale across your organization.
If you’d like to leave a comment or request other demos, please leave a comment on our community post.
The post [Demo] See why Bitbucket + the Atlassian stack are better together appeared first on Bitbucket.
We are excited to announce the release of the Pipelines runner version 3.0.0, featuring more reliable and faster management of artifacts and caches. Whilst we work hard to avoid breaking-changes in runner versions, the scale of the enhancements made to version 3.0.0 have required us to make changes that mean versions of the runner prior to 3.0.0 will be impacted.
To maintain stable access to the self-hosted runner functionality, and gain the benefits from these improvements (as well as numerous other security and performance updates), all customers are required to upgrade to version 3.0.0 or above before December 2, 2024.
To see a history of changes, including any future updates, you can view the self-hosted runner changelog here.
How to update a runnerTo update your runners, please follow the guidelines outlined in the documentation here.
As part of this deprecation:
- No changes are required in your Pipelines configuration.
- If you use IP or URL allowlisting to control access to your internal networks from Pipelines, please review the following section.
Changes to IP AllowlistingIf you use IP or URL-based allowlisting to manage traffic to/from your runner infrastructure, please be aware that the runner now communicates directly with file storage in AWS S3. When upgrading to version 3.0.0 or above, please ensure that you unblock the following for both incoming and outgoing traffic:
IP The full list of Bitbucket Pipelines build environments outlined in the Pipelines documentation.*
URL* micros–prod-east–bitbucketci-file-service–files.s3.amazonaws.com
If you have any questions or concerns, please reach out to the team via the Pipelines space in Atlassian Community.
The post Bitbucket Pipelines Runner – Upgrade Required appeared first on Bitbucket.
As a reminder to our prior communication, if you signed up for the beta of our Atlassian Intelligence features in 2023, the free usage period ends tomorrow, August 16, 2024.
After this date, Atlassian Intelligence features are only available on the Bitbucket Premium plan. We encourage you to consider upgrading to maintain your access to these features, and get access to all our other premium features to help you accelerate development velocity across your teams.
Key benefits of upgrading to Bitbucket Premium:
- Increase developer productivity with built-in generative AI features
- Enforce merge checks to ensure code quality at scale
- Use dynamic pipelines to centrally manage CI/CD workflows
- Premium support, 24/7 for high impact issues
- 99.9% reliability SLAs
Learn more about our premium features.
How to upgrade: If you’re the admin of your workspace, go to Workspace settings > Plan details (in left nav) > Change plan. If not, please reach out to your admin to upgrade.
The post Grace period for beta users of Atlassian Intelligence features ends on August 16th, 2024 appeared first on Bitbucket.
We've postponed our plans to build support for data residency in Bitbucket Cloud until 2026.
We're doing this to make way for some exciting new features to supercharge the developer experience, including integration with Atlassian Rovo (our new AI tool), dark mode, CI/CD migration tooling to help you move from Jenkins to Bitbucket Pipelines, improving the pull request experience and adding several new security controls.
For customers who have a strict requirement for data residency, we recommend continuing to use Bitbucket Data Center.
Please fill out this quick survey and let us know what your specific requirements are in terms of data residency e.g. why you need it, which country you want your data to reside in, etc. These details will help us prioritize this feature during future roadmap planning discussions.
The post Roadmap update: Support for data residency in Bitbucket Cloud is postponed appeared first on Bitbucket.
As AWS CodeCommit sunsets its Git repository service, now is the perfect time to migrate your repositories to Bitbucket Cloud. Bitbucket Cloud offers a robust, feature-rich platform for managing your Git repositories, with seamless integration into the Atlassian ecosystem. This guide will walk you through the steps needed to migrate your repositories from AWS CodeCommit to Bitbucket Cloud, ensuring a smooth transition with minimal downtime.
Why Choose Bitbucket Cloud? Seamless Integration: Bitbucket Cloud integrates effortlessly with Jira, Confluence, and other Atlassian products, enhancing your team’s productivity. * Enhanced Collaboration: Bitbucket’s powerful pull request and code review features simplify collaboration and code quality control. * Accelerate Velocity: Eliminate tedious tasks with AI and automation across the Atlassian stack. Reduce distractions and context switching by centralizing developer workflows on one platform. * Strong Security: With built-in security features like IP whitelisting, two-step verification, and SOC2 Type II compliance, your code remains secure. * Scalability*: Bitbucket Cloud scales with your team, supporting large active repositories.
Migration PrerequisitesBefore you begin the migration process, ensure you have the following:
- Bitbucket Cloud Account: Sign up for a Bitbucket Cloud account if you don’t already have one
- AWS CLI: Ensure the AWS Command Line Interface is installed and configured with the necessary permissions.
- Git: Make sure Git is installed on your local machine.
Step-by-Step Migration GuideStep 1: Clone Your AWS CodeCommit RepositoryFirst, clone your AWS CodeCommit repository to your local machine.
```
Clone the AWS CodeCommit repository git clone https://git-codecommit..amazonaws.com/v1/repos/ cd
``
Replacewith your AWS region and
Step 2: Create a New Repository in Bitbucket Cloud1. Log in to your Bitbucket Cloud account. 2. Navigate to your workspace and click on Repositories. 3. Click on Create repository. 4. Fill in your repository details (e.g., repository name, description) and click Create repository. 5. Make sure the repository is empty upon creation (e.g. no readme or .gitignore file checked)
Step 3: Add Bitbucket Cloud as a RemoteAdd the newly created Bitbucket Cloud repository as a remote to your local repository.
```
Add Bitbucket Cloud as a remote git remote add bitbuckethttps://@bitbucket.org//.git
``
Replacewith your Bitbucket username,with your Bitbucket workspace ID, and
Step 4: Push Code to Bitbucket CloudThis will push all branches and tags to your new Bitbucket repository.
git push bitbucket --mirror
Step 5: Migrate Pull Requests (Optional)You'll need to first create a repository access token for Bitbucket API access Using Repository Access Tokens | Bitbucket Cloud | Atlassian Support. Give the token Pull Request write permission.
Never commit credentials to source code. Use an environment variable or key manager. You can also delete this repository access token once you've completed your migration.
Leverage the AWS SDK (boto3) and Bitbucket Cloud APIs to migrating pull request data. This is an example Python script that can be modified for your specific data migration needs. Replace the placeholder values in the script with your specific details. This script will fetch all open pull requests from your AWS CodeCommit repository and create equivalent pull requests in your Bitbucket Cloud repository. Note: This code is for demonstration purposes and unsupported.
First, ensure you have the necessary libraries installed:
pip install boto3 requests
Then, use the following script:
import osimport boto3import requests# AWS CodeCommit configurationsaws_region = os.environ['AWS_REGION']codecommit_repo_name = os.environ['CODECOMMIT_REPOSITORY_NAME']# Bitbucket configurationsbitbucket_workspace = os.environ['BITBUCKET_WORKSPACE_ID']bitbucket_repo_name = os.environ['BITBUCKET_REPOSITORY_NAME']bitbucket_access_token = os.environ['BITBUCKET_ACCESS_TOKEN']# Initialize AWS CodeCommit clientcodecommit_client = boto3.client('codecommit', region_name=aws_region)# Fetch all pull requests from CodeCommitpull_requests = codecommit_client.list_pull_requests( repositoryName=codecommit_repo_name)['pullRequestIds']for pr_id in pull_requests: pr_details = codecommit_client.get_pull_request( pullRequestId=pr_id )['pullRequest'] pr_title = pr_details['title'] pr_description = pr_details['description'] source_branch = pr_details['pullRequestTargets'][0]['sourceReference'] destination_branch = pr_details['pullRequestTargets'][0]['destinationReference'] # Create pull request in Bitbucket Cloud bitbucket_pr_data = { 'title': pr_title, 'description': pr_description, 'source': { 'branch': { 'name': source_branch } }, 'destination': { 'branch': { 'name': destination_branch } } } response = requests.post( f'https://api.bitbucket.org/2.0/repositories/{bitbucket_workspace}/{bitbucket_repo_name}/pullrequests', json=bitbucket_pr_data, headers = {"Authorization": f"Bearer {bitbucket_access_token}"} ) if response.status_code == 201: print(f'Successfully created pull request: {pr_title}') else: print(f'Failed to create pull request: {pr_title}. Error: {response.content}')print('Pull request migration completed.')
Step 6: Verify and complete your migrationAfter completing the migration, it’s crucial to verify that all data has been successfully transferred:
- Repository Content: Check if all branches, commits, and tags are present in the Bitbucket Cloud repository.
- Pull Requests: Verify that all pull requests have been correctly migrated, including their titles and descriptions.
- Permissions and Settings: Reconfigure repository permissions, webhooks, and other settings that were previously set up in AWS CodeCommit.
Step 7: Update Remote URLsIf you plan to continue working with the migrated repository locally, you may want to update the remote URL to point to your new Bitbucket Cloud repository instead of AWS CodeCommit. You can do this using the following command:
git remote set-url origin <bitbucket-repository-url>
ConclusionMigrating your repositories from AWS CodeCommit to Bitbucket Cloud doesn’t have to be a daunting task. By following these steps, you can ensure a smooth and efficient transition, leveraging Bitbucket Cloud’s powerful features to enhance your development workflow.
Are you ready to make the move? Start your migration today and unlock the full potential of Bitbucket Cloud!
Additional Resources* Bitbucket Cloud Documentation * AWS CodeCommit Documentation * Git Documentation
The post Migrating Your AWS CodeCommit Repository to Bitbucket Cloud appeared first on Bitbucket.
As part of our commitment to building for enterprise scale and security, we just released a new privacy feature to allow admins on a Premium plan to enforce privacy at the workspace level ensuring that all content created and maintained within projects and repositories is private.
Currently, a private Bitbucket workspace can contain both public and private repositories. Public repositories are used to collaborate with users outside your organization while private repositories can only be accessed by users who are part of your workspace.
We've heard from many of you that due to privacy and security concerns, you want to be able to restrict users from creating public repositories. With the launch of this feature, workspace admins can now check a box to ensure that all projects and repositories created within a private workspace are private.
How it worksTo enable this privacy setting, go to Workspace settings and select the Do not allow public content inside this workspace setting as shown below.
Note: If you have current content that is public, you will be prompted to change any public content to private before you can enable this setting.
Benefits of using this featureWith workspace privacy enforcement, you can expect:
- Increased Control: Workspace admins gain more control over their workspaces. You can decide whether or not you want to allow public content within your workspace.
- Enhanced Privacy: By enforcing that all workspace content is private, you can prevent accidental exposure of sensitive data. Users will not be able to create public content within your workspace.
- Better Tracing: Changes to content privacy and creation of content is tracked in audit logs available via Atlassian Guard.
Note that this feature is only available for customers with a Premium plan. If you're not on a Premium plan yet, learn more about all the additional features and upgrade to Bitbucket Premium.
What's next?We're continuing to invest in improving the privacy and security of workspaces and the projects and repositories within them. Over the next few months, keep an eye out for new features that will give you more controls to manage your workspace.
The post [New in Premium] Enforce private content in your workspaces appeared first on Bitbucket.
With AI technology advancing rapidly, we at Atlassian recognize its potential to accelerate collaboration, and are invested in infusing it into all of our Atlassian Cloud products. Launching our beta program was the first step to supporting teams with AI, and we're grateful for all who have joined us in this journey so far.
We first announced our beta of Atlassian Intelligence (AI) features in Bitbucket in October 2023. Since then, hundreds of teams have used generative AI in the editor to accelerate code review cycles and write faster with increased clarity. As we enter into the next stage of improving these features in Bitbucket, our AI beta period will be coming to an end on August 16, 2024.
What's next for AI in Bitbucket?After the conclusion of the beta period, AI features will only be available in Bitbucket Premium. For users who were a part of the beta program and would like to continue accessing AI features in Bitbucket, you will need to upgrade to a Premium plan in order to avoid disruption to your current functionality.
Over the coming months, we will continue to add more editor prompts specific to code and code review and continue to invest in Atlassian Rovo and AI integrations. We're excited to add both depth and breadth to our existing functionality:
AI-generated PR descriptions: Automatically generate pull request summaries based on code changes and commit messages.
Generative AI editing: Let AI assist in editing and enhancing the tone of comments, giving reviewers time back to prioritize impactful changes.
Atlassian Rovo (Beta): Find information across SaaS apps, learn and absorb project context faster, and accelerate productivity both within code and beyond it.
AI Integrations: Use your preferred AI tool to get code suggestions with context from your Bitbucket repositories or have AI take a first pass at code review.
If you're interested in upgrading to Premium to continue accessing AI features, you'll also get more granular access controls, and enforced code quality and compliance at scale. For more instructions on how to upgrade to Bitbucket Premium, please refer to this page on plans and billing.
The post What’s next for Atlassian Intelligence (AI) in Bitbucket appeared first on Bitbucket.
On July 15, 2024, Bitbucket began to update its Transport Layer Security (TLS) configuration to be consistent with other Atlassian Cloud products. This includes ending support for some weaker cipher suites.
This change is not being made in response to any breach or issue, but as part of our continuous efforts to ensure our products maintain our best-in-class security for our customers.
This change affects all HTTPS traffic to Bitbucket, including:
- https://bitbucket.org
- https://api.bitbucket.org
- Repository operations against https://bitbucket.org
- Hosted sites on https://*.bitbucket.io
This change does not affect:
- Repository operations via SSH (bitbucket.org or altssh.bitbucket.org)
Supported cipher suites as of July 15, 2024As of July 15, 2024, your browser, client, or CI server must support making TLS connections using at least one of the cipher suites below.
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
What cipher suites are deprecated?As of July 15, 2024, the following cipher suites are no longer supported.
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
How can I tell if I am affected by this change?We will be contacting some teams and users directly, based on what we find in our logs. If you’d like to be proactive, though, then be sure to check all of the things that you use to connect to Bitbucket, including (but not limited to) your browser, your Git client, your CI/CD system, any API clients, and anything else you may have linked to Bitbucket.
I’ve found an affected library or client, or you’ve contacted me to tell me that I will be affected by this change. What do I need to do?Immediately upgrade anything that is affected to one of the supported cipher suites listed above. We understand that system upgrades can be complicated, especially on shared systems, but keeping your repositories secure is a priority for us. We appreciate your support and patience as we disable old, insecure cipher suites.
Additional resources* Supported security protocols for Atlassian cloud products
The post Update: Supported cipher suites for Bitbucket Cloud appeared first on Bitbucket.
Note: This is a follow-up to a May 2023 blog post about Bitbucket Cloud IP address changes. It includes updates to the list of IP addresses, as well as to the rollout timing.
Earlier this month, we began migrating traffic to use new IP addresses for bitbucket.org. We expect to finish the migration by July 31, 2024. The old IP addresses are now deprecated, and we will begin to retire them starting August 31, 2024.
There will not be any downtime for this migration, and most users will not have to do anything differently because of this migration.
Developers, teams and organizations that use a firewall, access list, security group or other network policy to restrict outgoing access to a particular IP will need to update their rules to permit connections to our new addresses.
The change does not affect the IPs used by Bitbucket to connect to remote servers, such as for webhooks.
Why are we doing this?Bitbucket has seen amazing growth over recent years, with millions of developers and teams using it to build better software.
Continuing our commitment to performance and reliability, we'll be making enhancements to our network edge, introducing additional points of presence in the US, Europe and Asia.
This necessitates the addition of new IP addresses to our IPv4 A and IPv6 AAAA DNS records.
How will this affect you?Most users will not have to do anything special for this change. Your DNS servers should pick up the new IPs within a few minutes, and your systems should start using the new IPs right away. The old IP addresses are now deprecated; bitbucket.org will be served from them until August 31, 2024, from which point we will begin to retire them.
Firewall considerationsIf you control access to Bitbucket from your network with a firewall, then you may need to update your configuration. Please ensure these new IPs are allowed through your firewall.
The new destination addresses for bitbucket.org, bitbucket.com, api.bitbucket.org, bitbucket.io, bytebucket.org, altssh.bitbucket.org are listed below.
IPv4:
104.192.136.0/21185.166.140.0/2213.200.41.128/25
IPv6:
2401:1d80:3000::/36
These ranges are completely owned and controlled by Atlassian, however they do include Atlassian products other than Bitbucket.
Deprecated IP addressesAs a result of this migration, the following IP ranges and IPs have been deprecated. Deprecated IPs will begin to be retired from August 31, 2024.
IPv4:
18.205.93.0/25(deprecated)18.234.32.128/25(deprecated)13.52.5.0/25(deprecated)
IPv6:
2406:da00:ff00::22cd:e0db(deprecated)2406:da00:ff00::6b17:d1f5(deprecated)2406:da00:ff00::3403:4be7(deprecated)2406:da00:ff00::22c3:9b0a(deprecated)2406:da00:ff00::22c5:2ef4(deprecated)2406:da00:ff00::22c2:0513(deprecated)2406:da00:ff00::34cc:ea4a(deprecated)2406:da00:ff00::22e9:9f55(deprecated)2406:da00:ff00::22c0:3470(deprecated)2406:da00:ff00::34c8:9c5c(deprecated)2406:da00:ff00::12d0:47c8(deprecated)2406:da00:ff00::22ed:a9a3(deprecated)2406:da00:ff00::23a8:5071(deprecated)2406:da00:ff00::36ec:9434(deprecated)2406:da00:ff00::3416:7161(deprecated)2406:da00:ff00::36ec:bea6(deprecated)2406:da00:ff00::12cd:ae3d(deprecated)2406:da00:ff00::12cc:b432(deprecated)2406:da00:ff00::1714:aa06(deprecated)2406:da00:ff00::342d:4312(deprecated)2406:da00:ff00::22ee:e721(deprecated)2406:da00:ff00::34cf:03c4(deprecated)2406:da00:ff00::3657:a859(deprecated)2406:da00:ff00::1716:0c22(deprecated)2406:da00:ff00::36ec:507a(deprecated)2406:da00:ff00::3448:67ee(deprecated)2406:da00:ff00::36ad:fb4d(deprecated)2406:da00:ff00::22ce:9394(deprecated)2406:da00:ff00::12d0:5d6e(deprecated)2406:da00:ff00::3402:732e(deprecated)2406:da00:ff00::36d1:8b98(deprecated)2406:da00:ff00::3414:6492(deprecated)2406:da00:ff00::3437:b4cb(deprecated)2406:da00:ff00::22e2:3a76(deprecated)2406:da00:ff00::34c9:c443(deprecated)2406:da00:ff00::3405:6cad(deprecated)2406:da00:ff00::12ea:0a19(deprecated)2406:da00:ff00::23a8:6621(deprecated)2406:da00:ff00::3401:9341(deprecated)2406:da00:ff00::3654:c786(deprecated)2406:da00:ff00::3448:4e57(deprecated)2406:da00:ff00::36a4:e08c(deprecated)2406:da00:ff00::36a4:f8a6(deprecated)2406:da00:ff00::22c8:ada3(deprecated)2406:da00:ff00::34cd:a4b9(deprecated)2406:da00:ff00::23a8:b9b1(deprecated)2406:da00:ff00::3402:affc(deprecated)2406:da00:ff00::12cd:d438(deprecated)2406:da00:ff00::34ce:b43b(deprecated)2406:da00:ff00::342d:1804(deprecated)2406:da00:ff00::36ae:07e7(deprecated)2406:da00:ff00::3456:314c(deprecated)2406:da00:ff00::36af:42a0(deprecated)2406:da00:ff00::3414:0248(deprecated)
SSH considerationsOur server’s SSH key is not changing, so most SSH clients will continue to work without interruption. However, a small number of users may see a warning similar to this when they push or pull over SSH:
Warning: the RSA host key for 'bitbucket.org' differs from the key for the IP address '18.205.93.1'
The warning message will also tell you which lines in your ~/.ssh/known_hosts need to change. Open that file in your favorite editor, remove or comment out those lines, then retry your push or pull.
Additional resourcesThese resources have been updated with the new IP addresses:
- Atlassian Public IP ranges JSON: https://ip-ranges.atlassian.com/
- Bitbucket support documentation: https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html
The post Update: New IP addresses for Bitbucket Cloud appeared first on Bitbucket.
Pull requests are a core feature of Bitbucket Cloud, serving as the hub where code contributions are reviewed, discussed, and approved before being merged into the codebase. Initially, developers focused on ensuring that proposed changes were bug-free, adhered to correct code styling, and included appropriate tests. Over time, the role of pull requests has expanded to act as a checkpoint, ensuring that only high-quality and compliant code reaches production.
As the responsibilities associated with pull requests grew, the need to scale and automate the review process became more pressing. Classic Merge Checks have been instrumental in this, allowing users to select from a range of predefined checks that must be satisfied before a pull request can be merged. Checks like minimum number of reviewers, successful builds, and no unresolved tasks have significantly reduced production incidents.
Recently, Bitbucket introduced custom merge checks, marking the next step in this evolution. Feedback from customers and internal Atlassian teams highlighted the demand for additional types of merge checks and greater configurability. Many use cases were highly specific – either to a certain business domain, or even a certain organisation, making it challenging to generalize solutions for the entire Bitbucket user base.
For instance, Atlassian's internal compliance requirements necessitated a merge check to ensure that each pull request was reviewed by a specific set of reviewers, based on an internal system.
Making Merge Checks pluggableTo accommodate diverse use cases, we made Merge Checks pluggable through Forge, Atlassian's Extensibility Platform. This allows anyone to quickly build and deploy extensions hosted within Atlassian's infrastructure, and then plug those extensions directly into the core Pull Request workflow, as if they were part of the native Bitbucket Cloud product. Custom Merge Checks enable customers and marketplace partners to create their own merge checks tailored to their specific needs. With just a few lines of code, you can develop a Custom Merge Check app to enforce your merging requirements.
For example, an Atlassian team created a Custom Merge Check to ensure sufficient approvals from the code owners before merging a pull request. Other use cases include checking to see if the linked Jira issue has progressed in its workflow to a ‘ready to merge’ state or calling out to the service management tool if the time is later than 5pm, to confirm that there are available support representatives before executing an after-hours deployment.
Here are links to documentation, and a step by step of how to build a sample app (one, two)
Required or recommendedIntroducing new rules can often be contentious, and this is also true for rules governing when a pull request can be merged. To address this, Custom Merge Checks in Bitbucket can be configured as either “Required” or “Recommended.” Required Checks must pass for the pull request to be merged, whereas recommended checks will provide in-context advice and guidance to reviewers, without blocking the pull-request if they don't pass. This flexibility allows teams to introduce new checks and gauge their impact before making them mandatory.
For instance, you might create a Check that only allows pull requests to be merged if the code coverage remains high. Initially, this target might not be met, but it can motivate your team to improve, eventually making it an enforced standard to maintain high coding quality.
Scaling Merge ChecksScaling the checkpoint role of code reviews goes beyond a single repository. Standardizing Checks across all repositories is crucial, particularly for larger companies. At Atlassian, we rely on custom scripts to ensure all repositories have the necessary compliance controls. Repositories without these controls are blocked from deploying.
To address use cases like this, an upcoming release of Bitbucket Custom Checks will introduce workspace- and project-level checks. This addition will enable workspace and project administrators to establish and enforce policies that apply uniformly across all repositories within their workspace.
Repository administrators will retain the flexibility to introduce additional checks specific to the unique needs of their repositories. This dual-layer approach allows for both broad standardization across the organization and granular customization at the repository level, providing the best of both worlds.
For instance, the Atlassian compliance team is working on creating a comprehensive Custom Merge Check to ensure that every pull request adheres to stringent compliance requirements. This includes verifying that each pull request undergoes a minimum number of appropriate reviews, ensuring that all reviewers have approved the latest version of the pull request, and confirming that all necessary compliance controls are enabled for the repository.
To guarantee that this Custom Merge Check is consistently applied across every Atlassian code repository, the team will leverage the new workspace-level configuration feature. This ensures that all repositories, regardless of their individual settings, adhere to the same high standards of compliance and quality.
ConclusionThe value of pull requests continues to grow, enhancing code quality at the repository level and serving as checkpoints for organizations to support standardization and ensure compliance across their entire codebase. Bitbucket Custom Merge Checks support this evolution by making merge checks pluggable, allowing for easy implementation of business-specific custom rulesets. Additionally, these checks can be broadly rolled out across your organisation to maintain consistent standards.
We are continually expanding the capabilities of Custom Merge Checks and are eager to hear your feedback and ideas.
The post Scale your code review with custom merge checks appeared first on Bitbucket.
We recently gave you a preview of some exciting changes coming to Bitbucket Pipelines with the release of our next-generation CI/CD runtime. This new runtime will act as the foundation for a range of powerful new future capabilities like ARM and multi-arch builds in cloud, and we're excited to announce that this new runtime is available starting today.
With today's launch, you can enable significantly larger instance sizes for your CI/CD workloads – giving your teams up to 8x more CPU and memory for their builds.
Important: This post includes a deprecation notice for Pipelines’ legacy cloud runtime. If you use IP allowlisting as part of your CI/CD setup, it is important you review the "Retirement of legacy runtime and IP changes" section below.
Increase CPU and memory allocation for your buildsYou can now specify two new sizes for your builds running in Bitbucket Pipelines with the new 4x and 8x build sizes.
Any builds run with these new size properties will automatically be provisioned on the new runtime which gives them access to both increased CPU and memory, as well as dedicated compute resources that are assigned exclusively to your builds.
We're reworking the build size numbering scheme for Bitbucket Pipelines, starting with 4x & 8x which will be moving to a standardised sizing ratio with dedicated CPU and memory that scales directly in line with the increased build size number.
For reference:
- 4x builds will be provisioned with 8 CPU cores and 16GB of memory.
- 8x builds will be provisioned with 16 CPU cores and 32GB of memory.
New Pipelines runtime:Steps using the new 4x and 8x sizes will automatically be set up on the new Pipelines runtime, whilst steps running on the existing 1x and 2x sizes will continue using the legacy runtime until September.
It's important to be aware that there are some underlying changes to the Pipeline platform that, in extremely rare scenarios, may cause unexpected behaviours in your builds.
If your builds rely on specific elements of the current runtime environment (such as specific Linux kernal versions, or specific numbers of CPU cores being visible to the build container), we recommend you do detailed end-to-end testing of your builds on the new runtime, prior to making it your default execution environment.
Not sure if this applies to you? Then you shouldn’t need to worry about it.
Retirement of legacy runtime and IP changesOn September 17th, 2024, we will be retiring the legacy Pipelines runtime for builds running on 1x and 2x sizes. Those step sizes will be automatically migrated to the new Pipelines runtime, as part of this process.
To be clear, 1x and 2x sizes are not being retired, they are simply being moved to the new Pipelines runtime.
As part of this deprecation:
- No changes are required in your Pipelines configuration.
- If you use IP allowlisting to control access to your internal networks from Pipelines, please update to the new IP address ranges for the new runtime as listed in the Pipelines documentation prior to September 17th.
We recommend conducting some basic end-to-end testing of your 1x and 2x builds on the new 4x build size prior to September 17th, even if you do not intend to use the larger step sizes for production loads. This will give you a chance to identify any potential incompatibilities between your current CI/CD workflow and the new runtime.
For context, Atlassian has been running on this new runtime for it's internal CI/CD for an extensive period of time and has completed millions of builds with it, with no major incompatibility being experienced.
The post Announcing our new CI/CD runtime, with up to 8x faster builds appeared first on Bitbucket.
Hello, Bitbucket Cloud Community!
We are incredibly excited to announce the introduction of Iterative review, a feature designed to help your team get pull requests completed faster by removing the need to re-review code you've already seen. Now when an author pushes new commits based on your pull request (PR) feedback, you'll have the option to focus on just those new changes.
How it worksAny time you finish reviewing a pull request, Bitbucket makes note of the last commit you viewed. For purposes of this feature, here are the different actions that constitute "reviewing":
- Approving the PR
- Requesting changes
- Marking all files as viewed
- Submitting batched comments (with or without approval status)
When the author makes new commits to the PR, you'll then have the option to view just the changes made since your last review. This is possible thanks to a new dropdown on the "Files changed" tab that controls your diff view for the pull request.
By default this dropdown is set to "All changes", meaning you're be looking at the full changeset on the source branch. This is the view that we've always shown on pull requests. When you switch the dropdown to "Changes since last review", Bitbucket then shows you just the files changed in the commit(s) since you last reviewed the PR. The number next to "Files changed" is updated to reflect the number of files you're viewing.
The "Changes since last review" option will only appear when a PR has new commits that you haven't seen. Remember that your last-reviewed commit is specific to you as a user, so your teammates may see a different view of the PR, depending on how much of it they've already reviewed.
At any time during a pull request, you can also select an arbitrary commit (or range of commits) in the dropdown, allowing you to focus on any part of the PR's history.
Things to considerBitbucket will always default you to "All changes" mode – the incumbent functionality on pull requests up to now – but we think you'll find iterative review to be useful in many situations. The ability to look at just a slice of a pull request is a powerful feature, and it may take some getting used to. Here are some important considerations when using iterative review:
- When you are looking at a PR in "Changes since last review" mode (or with a custom diff range selected), any comments you make will be associated with that diff range. Other PR viewers will be able to access these comments from the activity feed or by using the comment navigation dropdown.
- We don't currently support showing "Changes since last review" if a PR has had a merge commit or destructive force push since your last review.
Learn more about pull request review
Get started todayIterative review is available today for all teams using Bitbucket Cloud. As always, please feel free to share your thoughts with us through the help '?' menu > Give feedback.
The post Focus on recent code changes with iterative review appeared first on Bitbucket.
Exciting news for Bitbucket users! You now have direct access to notifications right within Bitbucket. To view your notifications, simply click on the notifications (bell-shaped) icon on the top navigation bar.
Bitbucket will display notifications for pull requests, comments, mentions, reviews, and status changes. If your Bitbucket workspace is linked to a Confluence or Jira site, you'll also receive notifications from Confluence and Jira. Additionally, notifications from Bitbucket will appear directly within Confluence and Jira.
We designed notifications to make prioritizing your work even easier and help you stay on top all your Atlassian products.
The Atlassian team has been using Bitbucket notifications for the past few months, and we're excited for you to start using them as well!
The post Notifications in Bitbucket make it even easier to prioritize your work! appeared first on Bitbucket.
The code insights functionality in Bitbucket Cloud provides a variety of reports, annotations, and metrics to help your team have full context during the code review process.
With code insights, you can automatically have artifacts such as static analysis reports, security scan results, artifact links, unit test results, and build status updates appear in your pull request screen so reviewers have access to all reports and statuses before they approve the code change.
These artifacts appear in the reports widget in the UI and can be expanded to a modal that shows report details.
Code insights consist of two main components – reports and annotations. Reports are the artifact that shows any information you want to share. Annotations are individual findings that have been identified as part of a report, such as a line of code indicating a vulnerability. These annotations can be attached to a specific file and even a specific line within that file.
These can be created using the Bitbucket Cloud APIs described below. If the API calls are made within Bitbucket Pipelines, you simply need to send your request through a proxy server that runs alongside with every pipeline on localhost:29418, which will automatically authenticate your request.
curl --proxy "http://localhost:29418" --request PUT "http://api.bitbucket.org/2.0/"
If you're using a custom pipe to call the APIs, you can still utilise the same proxy server. However, due to the fact that pipes run within a docker container, the URL will be slightly different.
curl --proxy 'http://host.docker.internal:29418' --request PUT "http://api.bitbucket.org/2.0/"
Alternatively, you can refer to this page for an overview of the various authentication methods supported for calling the APIs outside of Bitbucket Pipelines.
Creating ReportsWhen creating a report, it’s important to generate a unique ID that is distinct across all reports for that commit. You can utilise this API endpoint to create a report. This same endpoint can also be used to update existing reports. Furthermore, the URL URL is available as both a GET and a DELETE endpoint to retrieve and remove the report.
Creating AnnotationsSimilar to reports, annotation needs to be created with a unique ID through this API endpoint. The same endpoint can also be used to update existing reports and is accessible as a GET and as a DELETE endpoint to retrieve and remove the annotation. Furthermore, this other API endpoint provides bulk options, enabling the creation or update up to 100 annotations at once.
Using bitbucket-pipes-toolkitAdditionally, if you are using Bitbucket Pipes, you can create reports and annotations with the bitbucket-pipes-toolkit package. Create an instance of the CodeInsights class, then you can call the create_report and create_annotation methods, and pass in the necessary parameters to produce reports and annotations.
Sample Official PipesBelow are some of the official Pipes we offer, which utilise code insights. You can reference them to gain a better understanding for creating reports and annotations:
- git-secrets-scan – Scan your files for hardcoded sensitive data and create a security report. The secret leaks will be annotated in the code review as a comment, so that reviewers can easily discover and action them before merging code.
- checkstyle-report – Provide full insights based on Checkstyle result files generated by the build. This automation simplifies the reviewing of Java code, freeing developers from this boring but important task to ensure the code adheres to established standard.
- crate-ci-typos-check – Runs the typos CLI to find spelling mistakes among source code. Typos can be identified and annotated in file names or within the relevant files, allowing reviewers to have one less concern and focus on the code logic and quality.
Here’s a guide on creating a custom pipeline to streamline your company’s workflow: Code Insights | Bitbucket Cloud | Atlassian Support.
The post Provide full context to reviewers by including pipeline artifacts within the pull request appeared first on Bitbucket.
Here at Bitbucket Cloud, we are focused on helping you and your teams have the best possible experience for code review. That's why we continue to add features like batched comments, marking files as viewed, AI-assisted pull request descriptions – and coming very soon, iterative reviews.
We also want to give you the best possible experience navigating a pull request, which is why we're proud to be introducing a brand-new layout for pull requests. It's available for you to try as of today, and over the coming weeks we'll be rolling it out to all of our users.
What's new in the design?The pull request page is the place in Bitbucket where your most critical work gets done, and we've consistently heard a couple areas of feedback that we wanted to address:
- It can be difficult to understand what's changed recently, which is critical when you're returning to a pull request you've already viewed.
- Navigating PRs with a large number of files can be challenging with the existing sidebar file tree.
That's why we've moved to a tabular design that puts recent activity front and center, as well as providing a dedicated diff tab for full-screen code review. This design was heavily influenced by our sister product Bitbucket Data Center, so those of you who have used BBDC will find our new layout particularly familiar.
Rich activity feedRight away, you'll notice that we've moved the activity feed from the right sidebar to its own prominent space on the Overview tab. Here you'll find all the latest updates on the pull request – comments, approvals, new commits – in an easy-to-read format.
We've given particular attention to comment threads, which now include the context of code changes that they apply to. You can also reply to, resolve, and create tasks from comments right on the activity feed. And, when you need to, you can jump from a comment thread straight into the diff.
Focused code reviewThe Files changed tab provides a dedicated space for you to dive into code review. We've moved the file tree from the sidebar to the left of the page, a more natural location. If you like, you can fully collapse the file tree and side navigation for full-screen code review.
This new design for the diff includes all the viewing options you're used to, like side-by-side code review, hiding whitespace changes, and loading files individually so you can focus on one file at a time.
We think this new diff view works particularly well in single-file mode. To switch this on, go to the Files changed tab, select the cog icon, and then choose the option to load files individually.
Available todayStarting May 13, we've made the new layout available to all Bitbucket Cloud users on an opt-in basis. If you'd like to be one of the first to try it, visit Labs in your Bitbucket settings, then switch on the New pull request experience feature.
In the coming weeks we'll be gradually rolling out the new experience to users, so you can also just wait and you'll see it automatically. We know it can take time to adjust to a new layout, so as we're rolling out the feature, you will have the option to temporarily change back to the old view.
Starting June 10, the new layout will be fully rolled out, and we'll permanently retire the old view.
We'd love your feedbackHere at Atlassian, our teams have already been seeing the benefits of working with this more streamlined view of pull requests. And while we are confident that your teams will have this same experience with the new layout, we would love to hear from you after you've had a chance to try it.
If you have any feedback whatsoever – or if you've found a bug – please head to the Bitbucket help menu > "Give feedback" to share your thoughts with us.
The post Introducing 🥁 A new Bitbucket pull request experience appeared first on Bitbucket.
The context challengeUnderstanding and interacting with code repositories can be frustrating: you often don't get all of the information you need to get your work done efficiently and effectively. Who owns the repository? What are its dependencies? Where do I ask for help about interacting with it?
This lack of context around code, and the time it takes to find it somewhere in the bowels of your organization, slows everything down. It breaks your development flow, creates team bottlenecks, and takes longer for your organization to put valuable software into customers’ hands.
Thankfully, there's a way out.
The context cureCompass, a developer experience platform, lets you catalog the components of your software architecture (which include your code repositories), enrich them with data from across your toolchain, and define health standards to improve its performance.
The Compass software catalog, and a detailed view of one of its components. The Compass software catalog, and a detailed view of one of its components. The Compass software catalog, and a detailed view of one of its components. When you connect Compass to Bitbucket, you can bring the information about those components right into the code repositories they're associated with: to start, this means you'll see the component's owner teams, dependencies, and chat channels next to your code.
A repository linked to a Compass component, giving more context to the code. A repository linked to a Compass component, giving more context to the code. A repository linked to a Compass component, giving more context to the code. Having this context around your code is invaluable. You can see who owns it, where to go to get help with it, and what its dependencies are in your wider software architecture. This means less time searching for essential information, more time in development flow, and more confidence in your work.
Get started1. Get Compass for free, or request it for your organization. 2. Connect Compass to your Bitbucket workspace. You'll need to be an admin of the workspaces you want to connect to. 3. Create your Compass catalog using Bitbucket repositories, or link repositories to components you've already created.
Go to any repository's Sourcepage, and you'll see a Compass componentcard that shows the associated software component's owner team, dependencies, and chat channels.
What else would you like to see?As we continue to bring your code and software catalog closer together, we'd love to know how else you'd get value from integrating Bitbucket and Compass.
Let us know in the Compass Community.
The post Bring more context to your code with Compass appeared first on Bitbucket.
We're excited to announce the general availability (GA) of custom merge checks in Bitbucket Cloud. This new capability has seen amazing adoption and growth since entering into beta several months ago, and is now ready for prime-time having received a range of enhancements and improvements during the open-beta.
A brief summary of the changes going live with this GA release:
- Upgrades to the PR experience for "Classic" merge checks.
- Consolidation of PR checks experience.
- Introduction of
on-mergecustom checks. - Branch configuration for custom merge checks.
- "Recommended" vs "Required" custom merge checks.
For a full rundown of all the changes coming as part of the GA release, please head over to our detailed announcement blog from a few weeks ago.
How do I get started today?Custom merge checks are battle-tested and ready to go. You can get started building your own custom merge check apps today:
- We have comprehensive guides available on creating your own Forge apps in Bitbucket Cloud.
- Full example project repositories for custom merge checks.
- And pre-recorded live-code webinars to help you get started:
- Customize Bitbucket using Forge | Intro & Custom Merge Check live coding #ForgeDevDen
- AWS secrets scan merge check | Bitbucket custom merge checks to ensure compliance
And finally, take a look at the other areas that we’re enhancing through extensibility in Bitbucket Cloud like Dynamic Pipelines, as we continue our mission to become the world's most extensible cloud SCM and CI/CD product.
The post Custom merge checks are now generally available appeared first on Bitbucket.
Bitbucket cloud is on a mission to become the world’s most extensible cloud SCM and CI/CD product, and we're thrilled to be able to share the next stage of that journey.
Upcoming Webinar: Join us for a live-webinar on May 8th/9th, 2024 for a deep-dive into building your own Dynamic Pipelines.
Today, we're announcing the release of a new capability in Bitbucket Cloud called Dynamic Pipelines. This enhancement augments the core Bitbucket Pipelines functionality, adding highly intelligent and flexible CI/CD workflows that benefit individual teams as well as entire organisations.
Note:* Dynamic Pipelines is a Premium Feature and is available for all Bitbucket Cloud premium workspaces* as of today.
Traditionally, pipeline workflows, defined in YAML files, have been quite static and rigid. This can make it challenging to manage and implement sophisticated workflows that need to dynamically change based on varying conditions, external contexts, or inputs from outside the pipeline itself. Dynamic Pipelines represent a significant advancement, offering unprecedented levels of flexibility in managing pipeline workflows at all levels.
Orchestrating CI/CD across your entire organisationDynamic Pipelines heralds a new era in organisational CI/CD orchestration, setting a new, market-leading standard. With this capability, organisations can centrally oversee CI/CD workflows across their entire workspaces via logic stored in-code. This promotes standardisation and reusability of CI/CD workflows, enhances process management and compliance enforcement, and enables powerful new automation options. This unified approach simplifies the management of complex CI/CD architectures across entire organisations, making it an invaluable tool for centralised platform-style teams.
How Dynamic Pipelines workDynamic Pipelines operate by utilising Atlassian's Forge extensibility platform to allow users to create serverless functions directly integrated into pipeline workflows. As a pipeline prepares to execute, these user-defined functions receive the pipeline's configuration and can alter this configuration in real-time. This modified workflow is then sent back to the Pipelines platform for execution. This functionality not only means greater workflow adaptability, but also enhances the opportunities for customisation thanks to its implementation through familiar coding processes and tools.
What can you do with Dynamic Pipelines?Dynamic Pipelines are extremely flexible and offer a broad range of capabilities, far more than we could list here (or that we could even define ourselves).
However, the list below provides a high-level overview of just some ways Dynamic Pipelines are already being utilised by Atlassian teams today:
- Utilising environment, repository, or workspace variables to define docker image names for use in CI/CD workflows.
- Ensuring all builds run within an organisation are executed using docker images from a pre-approved list.
- Ensuring all builds within an organisation are executed on self-hosted runners.
- Implementing selective test execution in large monorepos based on pull request change-sets.
- Creating standardised and reusable 'blocks' of CI/CD workflows that can be defined & shared by platform engineering teams, and then consumed by multiple engineering teams within an organisation.
- Dynamically assigning jobs to runner agents tagged with certain cost-centre codes to automate cloud infrastructure cost attribution.
- Building an entirely customised
bitbucket-pipelines.ymlsyntax that can be used to auto-generate pipeline workflows at runtime from a set of tags and labels.- Stay-tuned for a case-study we plan to publish going into detail on exactly how this was built!
Dynamic Pipelines for individual teamsDynamic Pipelines are extremely powerful at the level of individual teams. By configuring a Dynamic Pipeline at the repository level, teams gain the ability to adapt their CI/CD workflows with greater intelligence and flexibility. The use of Forge as an underlying platform allows teams to reuse, share, and collaborate on Dynamic Pipeline logic the same way they would with existing software projects they work on every day. Additionally, with Forge Remote, teams can execute Dynamic Pipeline apps on their own infrastructure, using their preferred coding languages and frameworks. These capabilities empowers teams to start quickly and efficiently, without the need to learn new tools, enhancing productivity and fostering innovation.
“Whole-of-business” CI/CD orchestration with workspace-level Dynamic PipelinesDynamic Pipelines aren’t solely for individual team use. Instead, they extend to entire organisations through the use of workspace-level Dynamic Pipelines. This feature allows central platform-engineering teams within a workspace to create an "umbrella" Dynamic Pipeline app that operates across every pipeline execution within that workspace.
Using this app, they can manage, coordinate, and oversee CI/CD workflows for the whole organisation from a centralised and easy-to-manage location. This integration works seamlessly with existing YAML-based repo-level workflows and repo-level Dynamic Pipelines, augmenting those existing workflows without replacing them. Teams retain control over their workflow inputs and initial modifications, with additional validations applied at the workspace level before pipeline execution.
How to get started todayGetting started is super simple, you can have your first Forge app up and running in less than thirty minutes.
- Take a look at the product documentation to understand how to setup and use Dynamic Pipelines in Bitbucket Cloud.
- If you’re new to forge apps, take a look at our "Hello world" tutorial app in Bitbucket Cloud.
- Once you're familiar with Forge, check out our step-by-step tutorial to build your first Dynamic Pipeline application.
- Review the Dynamic Pipelines Forge module reference documentation.
- And be sure to join the Forge for Bitbucket Cloud community group to ask questions, share ideas, and stay informed about all the changes coming in this space.
And finally, take a look at the other areas that we're enhancing through extensibility in Bitbucket Cloud like custom merge checks, as we continue our mission to become the world’s most extensible cloud SCM and CI/CD product.
The post Introducing Dynamic Pipelines: A new standard in CI/CD flexibility appeared first on Bitbucket.
We are excited to announce that cloud migration trials (CMTs) are now generally available for new Bitbucket Cloud workspaces.
Cloud migration trials enable you to use the full functionality of Bitbucket Cloud during an extended trial period, so that you can plan and execute your migration from Data Center.
Bitbucket Cloud has been focused on building for enterprise scale, security, and performance. Over the past year, we’ve launched several features like Unified User Management, custom merge checks, and Forge. And now, with the launch of cloud migration trials, we’re enabling enterprises to evaluate the latest that Bitbucket Cloud has to offer. Enterprises can use CMTs to create proof of concepts, run test migrations, and migrate their data to cloud.
Am I eligible for a Cloud Migration Trial?Cloud migration trials are being offered to all Data Center customers. For more on eligibility and trial length refer to the following support document: Cloud migration trials for Data Center customers.
How to start your cloud migration trial1. Navigate to the Cloud Migrations Portal. 2. Select your Bitbucket Data Center product, and select Activate Trial. 3. Follow the steps to create your new workspace. 4. When migrating to Bitbucket Cloud, migrate to the Atlassian Admin-enabled workspace that you created using this process.
Contact us to get expert advice on how to use your trial to migrate, along with recommendations on next steps.
Tools to migrate all your important dataThe free Bitbucket Cloud Migration Assistant (BCMA) enables you to migrate your content from Bitbucket Data Center, including all your users, repositories and pull request metadata. And we've recently updated BCMA to allow you to migrate groups and permissions as well.
Already migrating?* Cloud migration trials cannot be applied to existing cloud workspaces. When starting the cloud migration trial you will create a new workspace. * Please raise a support ticket for help with migration planning and execution.
Documentation* Learn more about cloud migration trials https://support.atlassian.com/migration/docs/cloud-migration-trials-for-server-and-data-center-customers/ * Use this checklist to start planning your migration * Get the Bitbucket Cloud Migration Assistant app to easily migrate your content from Bitbucket Bitbucket Data Center to Bitbucket Cloud * If you have a complex migration and need help with implementation, connect with an Atlassian Partner
The post Cloud Migration Trials are available for Bitbucket Cloud! appeared first on Bitbucket.
Bitbucket Pipelines has seen amazing adoption over recent years, with millions of developers and teams using it to build better software every day.
As part of our ongoing commitment to improving performance and reliability, we are in the process of making enhancements to our cloud infrastructure.
These changes will also unlock a range of powerful new capabilities for customers that will turbocharge their CI/CD workloads and empower engineers to focus more of their energy on building great software.
Faster builds and more memory — powered by a new container runtimeAs part of these changes, we are moving to a new runtime under the hood. This new runtime uses microVM’s and runc to give us better capabilities in regard to how we assign compute resources to steps. Thanks to these changes, we are excited to announce the upcoming availability of 4x and 8x sized steps, releasing in June.
In addition to these larger step sizes, we are making changes to how compute resources scale with larger sized steps in order to unlock faster build speeds for our customers. In the past, when larger step sizes were used (2x vs 1x), the memory available to the build increased, but the amount of CPU remained the same. However, thanks to our new cloud runtime, we are now also able to scale the number of CPU cores available to larger step sizes (4x & 8x), in addition to the memory, more details will be shared in the coming weeks.
This runtime will initially only be available to 4x and 8x steps, with 1x and 2x steps being migrated over during August.
Changes to Pipelines IP address rangesTo enable the adoption of the new runtime, we are making changes to how IP addresses are assigned to the nodes that steps execute on.
If your team or organization uses a firewall, access list, security group or other network policy to restrict incoming access to particular IP's or IP ranges, you may need to update those rules to permit connections from our new addresses.
How will this affect youNOTE:* There will not be any downtime for this migration, and most users will not need to make any changes. However, there are* some changes that may be required in highly specialised setups.
For existing 1x and 2x stepsThere are no immediate changes for 1x and 2x steps. However, these step sizes will be migrated to the new runtime during August. At which point they will transition to run on nodes restricted to IP addresses provided by our cloud partner AWS.
These addresses can be found by using the following endpoint and using the us-east-1 and us-west-2 regions.
In order to avoid any disruptions in your Pipelines usage once the migration occurs during August, any allow-list policies in use should be updated to include these IP addresses.
For new 4x and 8x step usersAs the new 4x and 8x steps use the new runtime by default, they will run on nodes that use IP addresses provided by our cloud partner AWS.
These addresses can be found by using the following endpoint and using the us-east-1 and us-west-2 regions.
Any allow-list policies in use should be updated to include these IP addresses in order to take advantage of the new step sizes.
What if I need a more restrictive range of IP addresses?We understand that in some highly sensitive scenarios, a more restrictive set of IP addresses may be desired in order to limit the range of IP's that are allow-listed in your firewall.
To support this, we are adding an option for 4x & 8x steps that will allow you to execute those steps on a dedicated pool of nodes, restricted to a narrower sub-set of persistent IP addresses.
Note: This option is only available to 4x & 8x steps
The post Evolving Bitbucket Pipelines to unlock faster performance and larger builds appeared first on Bitbucket.
We are thrilled to announce that AI-assisted pull request descriptions is now available for all Bitbucket Premium users. Crafting clear, concise PR descriptions for complex changes can be time-consuming and frustrating. We know the struggle is real.
We, at Bitbucket, believe developers should spend less time writing descriptions and more time writing amazing code. That’s why we are excited to introduce this feature to streamline your workflow and empower you to write better PR descriptions faster.
One click to smarter descriptionsAtlassian Intelligence analyzes your code changes and commit messages to gain a deep understanding of the context behind your work. It then uses this information to generate a PR description that effectively captures the key aspects of your changes.
Here’s how it works:
- When creating a pull request, open the editor to compose the PR description.
-
Click on the Atlassian Intelligence icon in the editor prompt or type /ai to access the AI editor prompt.
-
Select ‘Create pull request description’ to generate the description.
-
You will receive a concise summary of your pull request. Simply click ‘Insert’ to accept the suggested changes.
But remember, you're still in control! The suggested descriptions are just a starting point. You can edit and refine the text to add your own insights and details.
Get started todayAI-assisted pull request descriptions are part of the Atlassian Intelligence (AI) feature set for Bitbucket Cloud, and can be activated for customers with a Premium plan. To enable Atlassian Intelligence, a workspace admin can go to Workspace settings > Atlassian Intelligence and accept the terms of service.
If you are a Free or Standard customer who previously participated in the open beta of Atlassian Intelligence, you will continue to have access to all the AI features (including AI-assisted pull request descriptions) in Bitbucket Cloud through June 30th, 2024. After this date, to retain access to AI features, you will need to upgrade to a Premium plan.
We're confident this feature will significantly enhance your developer experience. That being said, we'd love to hear your feedback and how you use AI-assisted pull request descriptions!
Learn more about our AI-assisted features
Happy coding!
The post Generate Bitbucket Cloud pull request descriptions with Atlassian Intelligence 🎉 appeared first on Bitbucket.
Today, modern software organizations’ requirements for DevOps tooling has become more sophisticated and bespoke. We hear from many customers that they are building large, complex systems to augment and extend their DevOps workflows in ways that don't work well with the tools they're using.
This is why Bitbucket Cloud is on a mission to become the world's most extensible cloud SCM and CI/CD product. Because we believe every modern software enterprise should be able to customize and extend their software development workflows to meet the exact needs of their organization – and that extensibility is key to operating effectively in the Cloud.
As part of our mission to empower our customers with greater extensibility, we're excited to share significant improvements to Bitbucket Cloud that will help organizations streamline workflows, elevate code quality, andgive developers even more space to deliver real value.
All of these features are built on top of Atlassian’s powerful Forge developer platform, implemented inside Bitbucket Cloud, to give our customers the flexibility and power to solve any business problem they encounter, no matter how bespoke or specialized.
Sign up for our webinar on May 8/9th, 2024 to learn how to use these features to build smarter CI/CD pipelines.
Improve code quality with sophisticated and flexible workflow controlsToday in Bitbucket many customers take advantage of our popular merge checks feature, which lets you enforce certain conditions on pull request merges (eg builds passing, minimum number of reviewers, completion of all pull request tasks, etc…). However, we've heard from customers that they want the ability to define their own criteria before allowing code to be merged into a repository via a pull request.
That's why we built custom merge checks (currently in open-beta). Custom merge checks allow teams to define specific conditions, rules, and processes as code and ensure those conditions are met before allowing code to be merged into a repository via a pull request. With custom merge checks, teams and organizations gain more control over their codebase; empowering them to maintain higher code quality, with less human review and intervention.
We're excited to announce that after a successful open-beta, custom merge checks will be entering general availability (GA) in late April 2024. For an overview of all the changes coming in the GA release, check out our companion blog.
Get started with custom merge checks today. We've had over 3K customers join our custom merge checks open beta since releasing it in December '23 and we've heard great feedback! To learn how to get started check out our documentation or pre-recorded live webinar. Got questions? Join us for a live demo and Q&A on April 9.
Standardise organisation-wide processes & policies all from a single placeCurrently, custom merge checks are available at a repository level, but soon after GA we will be making them available at the workspace level as well. This will make it possible for central DevOps or platform teams to define, standardise, and enforce organisation-wide processes and policies — all from a single location.
This new capability, coupled with updates coming for GA to enable "required" vs "recommended" check enforcement, will provide customers with a powerful new suite of tools. In addition to enforcing required practises and policies, customers will be able to empower teams with contextual suggestions and reminders regarding best-practises and ways of working that provide real-time, context aware feedback to software engineers as they complete their work.
Coming soon: Intelligent CI/CD workflows with dynamic pipelinesToday with CI/CD, workflows have to be defined up-front and are static, making them inflexible and often difficult to work with in more complex situations.
As part of our focus on Bitbucket Cloud extensibility and customisability, we're excited to share dynamic pipelines – on our near-term roadmap – that will significantly improve the way customers manage their CI/CD processes and workflows.
With Dynamic Pipelines, customers have the power to create CI/CD workflows that can adapt to changes in the development environment in real-time. Developers can modify pipeline behaviour at runtime using code, allowing for automated adjustments based on inputs such as branch name, commit message, files-impacted, or even information retrieved from systems external to Bitbucket Cloud entirely.
This will help DevOps teams improve with use cases like optimised builds, smarter test-execution, and workflows that can change and adapt based on external context.
Scaled CI/CD management for DevOps and platform teamsDynamic Pipelines aren’t just for individual teams – this powerful capability is set to become the industry’s most powerful solution for managing CI/CD operations in large organizations. While repository-level Dynamic Pipelines empower individual teams to optimize DevOps workflows, workspace-level Dynamic Pipelines provide the ultimate tool for organization-wide CI/CD orchestration.
Workspace-level Dynamic Pipelines enable centralized platform teams to define company-wide policies, rules, and processes as code — and enforce them across every repository within their workspace, all from a single centralized location.
This is a game-changing capability — giving customers the power to truly standardize, orchestrate, and automate DevOps workflows across an entire organization from one place. We're excited to announce that dynamic pipelines (at both the Workspace and Repository level) are on-track for launch in late April, just in time for Atlassian Team ’24.
Join us for a webinar diving deeper into dynamic pipelines in early May, and keep an eye out for our deep-dive feature blog on dynamic pipelines over the next few weeks.
Wrapping up – Customize your DevOps workflows!The upcoming GA releases of custom merge checks and dynamic pipelines are part of our journey to empower you to customize and extend your software development workflows to meet the exact needs of your organization. Get started with custom merge checks today and join us for our dynamic pipelines webinar in early May.
And if you're not using Bitbucket today as Atlassian's native code & CI/CD solution, give it a spin.
The post Uplevel your DevOps automation with new Bitbucket Cloud extensibility appeared first on Bitbucket.
As part of the graduation of custom merge checks from open-beta to general availability (GA) that is planned for late-April 2024, we're making a range of changes to several areas of the core Bitbucket Cloud workflow.
This includes changes to the core pull request review and authoring experience, as well as changes to how merge checks are configured within a repository.
Different changes will be relevant to different audiences, so feel free to use the navigation shortcuts below.
- "Classic" vs "Custom" merge checks
- Consolidating checks on pull requests
- Introduction of
on-mergechecks - Branch Configuration for Custom Merge Checks
- "Recommended" vs "Required" Custom Merge Checks
"Classic" vs "Custom" merge checksBefore discussing the changes, we need to define two terms:
- “Classic merge checks” refer to the traditional Bitbucket Cloud merge checks configured through branch restrictions in repository and project settings. They have basic UI configurability but cannot be customized.
- “Custom merge checks” refer to the new merge checks written as Forge apps by customers and third-party developers, installed, and configured to operate within specific Bitbucket Cloud workspaces.
Consolidating checks on pull requestsWe’re standardizing the workflow for enforcing and addressing both custom and classic merge checks on pull requests. Previously, they appeared in separate UI cards with slightly different behaviours.
With custom merge checks’ GA release, these cards will be consolidated into one. Classic checks’ behaviour will be standardized to match the updated UX introduced during the custom merge checks beta.
Introduction of on-merge checksWe’re introducing a new concept called on-merge checks, exclusive to custom merge checks (not supported by classic checks).
Classic pre-merge checks had to pass before attempting a pull request merge. on-merge checks, however, are integrated into the merge process itself. They run immediately after the user initiates the merge workflow, verifying conditions at the exact moment of code merge. If they pass, the merge processes instantly. If they fail, the merge is blocked with real-time feedback.
For app builders, you can define your custom check as on-merge by specifying it as a trigger in the Forge app manifest.
For pull request reviewers, on-merge checks will be clearly separated from traditional pre-merge checks in the pull request sidebar and merge workflow.
“pre-merge” vs “on-merge” examples:To better understand when to use each type:
“pre-merge” checks:Ideal for validating the code within the pull request itself. Pull requests reference immutable, linear git commits. As long as the latest commit meets requirements, the pre-merge check can pass, regardless of when commits were pushed.
Note: Some of you may have seen the edge-case here — what happens if the logic within the custom merge check app changes between the latest commit being pushed and the merge occurring? Don't worry, the custom merge checks framework has tools built-in to detect and manage this scenario too.
“on-merge” checks:Powerful for ensuring conditions are met at the exact merge moment. For example, blocking merges to the main branch after 5 PM Friday due to support team availability. The check runs during the merge process, validating the current state.
The key difference is that pre-merge checks validate the PR’s state at the time it was last updated, while on-merge checks validate conditions at the moment of merging.
Branch Configuration for Custom Merge ChecksCustom merge checks are configured differently from classic checks. There is a dedicated “Custom Merge Checks” tab in repository settings to manage their configuration.
The first decision is which branches the checks should run against:
“Main” Branch: Checks configured here only run against pull requests targeting the main/development branch.
“All” Branches:Checks configured here run against pull requests targeting all branches.
Note: You can add logic within your custom check app to make it more targeted, e.g., checking the source branch name and simply returning “success” if it doesn’t match a given pattern you determine for more refined targeting.
The flexibility is extensive, including the ability to create your own UI-based configuration screens at the workspace or repository level for custom merge check apps using Forge UI, allowing users to provide additional configuration data for the checks.
“Recommended” vs “Required” Custom Merge ChecksWe’re introducing a new capability with custom merge checks that allows repository administrators to configure the level of "strictness" for each individual check.
Previously, premium workspaces could require all merge checks to pass before merging a pull request, but there was no way to make some checks "required" and others "recommended".
With custom merge checks, premium workspaces can now configure each check as either "required" or "recommended" in the repository settings.
- Required checks prevent merging if they fail, enforcing critical business rules.
- Recommended checks display as suggestions but allow merging even if they fail, enabling teams to trial new processes or receive feedback without strict enforcement.
Non-premium workspaces can still enable custom merge checks as recommendations, but they cannot prevent merging if the checks fail.
This granular configurability empowers customers to enforce essential rules while gently guiding teams toward best practices and proper workflows through recommendations.
What's next?Custom merge checks are planned to enter GA in April. Until then, you can learn more about them and other upcoming capabilities such as dynamic pipelines on our recent update blog.
You can also get started building your own custom merge check apps today:
- We have comprehensive guides available on creating your own Forge apps in Bitbucket Cloud.
- Full example project repositories for custom merge checks.
- And pre-recorded live-code webinars to help you get started.
We will also be running a second live-code webinar focused on more advanced Custom Merge Check use-cases in early April, so come along and see how easy it is to get started.
The post Upcoming changes to pull requests and merge check configuration appeared first on Bitbucket.
As your team and products expand, expertise in various areas of your code base may become distributed among different team members, or across teams. This can create challenges when trying to identify the best qualified people to assign as pull request reviewers.
We have a new solution for this in Bitbucket Cloud: You can now designate suggested reviewers for specific areas of the code base by adding a code owners configuration file to your repository. This file is a set of rules describing which people own specific paths/patterns in your repository. Based on these rules, Bitbucket can then automatically assign reviewers to a pull request based on which files are being modified.
When you create a new pull request, Bitbucket automatically checks whether a CODEOWNERS file exists in the .bitbucket directory of the repository. If the file is found, every rule in that file is compared to the diff of your pull request. For each matching rule, the users associated with it are automatically added as suggested reviewers.
Learn more about code owners
Flexible and powerfulThe code owners syntax gives you the flexibility to assign individuals, groups or custom-defined teams as default reviewers for specific file paths or patterns. When working with groups and teams, you can specify how many reviewers to select, and how they should be chosen. Here are a few usage examples:
```
.bitbucket/CODEOWNERS# Default reviewers for files not matching patterns below alisha@example.com fred@example.com# Choose all members of a workspace group.js @workspace-slug/frontenders:all# Choose group members tagged on the fewest open PRs.py @workspace-slug/backenders:least_busy(2)# Choose randomly from a custom team (defined in teams.yaml).tf @teams/sre-leads:random(2)
``
Ready to see code owners in action? Simply add aCODEOWNERSfile to the.bitbucket` directory in your repository, then open a new pull request.
To learn more about code owners syntax, check out the reference guide.
Get started with smarter code reviewer assignmentThe code owners feature is available now for all teams using Bitbucket Cloud. We're excited about the potential of this feature to help your teams do better, smarter code reviews. As always, please feel free to share your thoughts with us through the help '?' menu > Give feedback.
The post Automatically assign code owners as pull request reviewers appeared first on Bitbucket.
We hosted a webinar on March 5th, 2024 to introduce you to what's possible with Forge, walk through some technical basics and answer any questions. Here is the recording link.
Sign up for our next webinar on April 9th, 2024, to learn more about how to set up a custom check.
Bitbucket Cloud is excited to announce the general availability release of our integration with Atlassian’s Forge extensibility platform, marking a significant step forward in our journey to build an infinitely extensible code and CI/CD solution; a concept we've labelled the DevOps Automation Platform.
Forge is Atlassian's cloud app development platform, allowing developers to host apps on infrastructure that is provisioned, managed, monitored, and scaled automatically by Atlassian. Forge provides a complete toolkit for extending Atlassian products.
This marks a significant milestone in crafting a system and strategy set to redefine the landscape of source control management and CI/CD solutions. Our ambition is clear: to position Bitbucket Cloud as the most extensible and integrated SCM & CI/CD solution in the market, offering an unmatched level of flexibility, without compromising on our core DevOps experiences.
Why is this important?We believe that the domains of software development and operation are of unparalleled complexity. As your organisation expands, its needs and requirements evolve, becoming more unique and bespoke, and this evolution demands refined, targeted solutions.
Some examples include things like additional compliance obligations, heightened privacy and data-security concerns, budgeting and internal accounting, and the inherent complexity that comes as your organisation adds more and more people.
The introduction of the DevOps Automation Platform, underpinned by our integration with Forge, is a key component of our response to these challenges.
We aim to empower you with a powerful toolkit, that you can tailor to you specific use cases. The DevOps Automation Platform, at its core, is designed to enable your teams to augment this toolkit with bespoke functionalities to meet your unique development requirements as they evolve over time.
Revolutionising DevOps with ForgeThis release marks a key moment in the evolution of cloud-based DevOps solutions. Traditionally, the flexibility and extensibility offered by an on-premises solution were unparalleled, leaving cloud offerings a step behind in terms of their ability to meet complex, customer-specific requirements. However, with Forge, this gap is finally able to be closed.
This initial release of Forge inside Bitbucket Cloud is aimed primarily at providing overall versatility to customers, focusing primarily on enabling users to enhance the frontend experience and automate backend processes triggered by critical system events. However, this is just the beginning. Forge is set to become the backbone for a suite of more specialised features aimed at solving complex business problems, from stringent compliance requirements to sophisticated orchestration of CI/CD pipelines.
Empowering Developers with Custom Merge Checks and Dynamic PipelinesDiving deeper into the specific applications of Forge within Bitbucket Cloud, we recently hit another milestone with the introduction of the Custom Merge Checks open beta and the upcoming introduction of Dynamic Pipelines.
Custom Merge Checks, which we launched just before the end of 2023, is a game-changer for teams seeking to enforce specific conditions before merges can occur, enhancing code quality and collaboration. Additionally, the introduction of Dynamic Pipelines later this year sets the stage for a future where CI/CD processes are not only automated, but intelligently responsive to the context in which they are executed, significantly elevating the efficiency of build and deployment workflows.
These features tell the story of the DevOps Automation Platform, facilitating a level of control and flexibility previously unattainable in cloud-based DevOps solutions.
So, how do I get started?To support you in taking full advantage of this exciting new capability, we’ve rolled out an array of resources aimed at bolstering developer success.
- Example repositories of fully-functional Forge apps:
- These offer developers a tangible starting point to understand, adapt, and extend functionalities within their own projects: Example apps for Bitbucket, Assign PRs randomly to a specific list of users in Bitbucket Cloud
- Comprehensive documentation to guide users through the process of Forge app implementation: Build a Bitbucket hello world app
- A dedicated community space for Forge app developers: Bitbucket Cloud x Forge – EAP
- And pre-recorded webinars, with more on the horizon, providing insights into leveraging Forge to its fullest potential:
In the future, we also plan on establishing open office hours with our engineering team. This would offer an unprecedented direct line to the team who are executing this program within Bitbucket Cloud, allowing for real-time questions, support, and feedback on app development.
An important note on support for Forge App developers:It's important to be aware of the support processes when it comes to the development and implementation of Forge apps in Bitbucket Cloud, as there are additional nuances compared to the core Bitbucket Cloud product.
So, to boil it all down, we will provide a high-level overview of the types of challenges you might run into, and where the correct place to go is for support.
- An issue with the Bitbucket API's, or the Bitbucket Forge extension modules.
- e.g. business events that previously worked are not firing, API calls that previously worked are failing, UI extensions that previously displayed are breaking.
- These kinds of issues would most likely be related to the underlying Bitbucket Cloud Forge integration, and can be addressed via the Bitbucket Cloud support channels.
- An issue with the underling Forge Platform.
- e.g. your Forge app won't deploy, you are not seeing correct information in the Developer Console.
- These kinds of issues would most likely be related to the Forge platform itself, and can be raised in the Ecosystem Community space or with the Ecosystem Support team.
- Any issues or help with your Forge App's code, "how to" type questions, or 3rd party Forge apps.
- This is the critical support boundary where Atlassian support teams cannot provide direct assistance as it is outside their scope.
- For any questions relating to building Forge apps, how to achieve particular outcomes, etc. – please join us in the Bitbucket Cloud x Forge community space where members of the engineering team, and other members of the community can support you.
- For any issues relating to Forge apps created by 3rd parties, please contact the app developer directly.
Forging Ahead: What’s Next for Bitbucket CloudAs we wrap up the beta phase of Bitbucket Cloud's integration with Forge, it's clear that this is just the beginning of the DevOps Automation Platform story.
Looking to the future, we're excited to evolve this platform with capabilities like Custom Merge Checks, Dynamic Pipelines, and all the other exciting solutions coming further down the line.
This is the beginning of a very exciting era for Bitbucket Cloud, and we're looking forward to having you all with us for the journey.
The post Forge for Bitbucket Cloud: Laying the foundation for infinite extensibility appeared first on Bitbucket.
We are excited to announce that unified user management is now generally available for new Bitbucket Cloud workspaces.
Unified user management brings Bitbucket user, group, and product access management to Atlassian Admin. This means that you can manage users across your Atlassian tools in one unified place and connect to external directories via Atlassian Access.
Bitbucket Cloud has been focused on building for enterprise scale, security, and performance. Over the past year, we've launched several features like project-level settings & permissions, batched commenting, enhanced-webhook security, autoscaling runners, and a lot more. And now, with the launch of unified user management, we're enabling enterprises to manage their users with enterprise-grade security and at scale.
Benefits of unified user managementWith unified user management, org and product admins will be able to:
- Integrate with Atlassian Admin: Provision and deprovision Bitbucket Cloud users via Atlassian Admin, which is the same way you manage user access to Jira Software, Jira Service Management, Confluence and Atlas users. This means a simpler, streamlined user management experience. No more having to manage Bitbucket users in a separate administration tool.
- Connect to external directories via Atlassian Access: Once Bitbucket is connected to Atlassian Admin, you will also be able to connect to third-party identity providers like Okta, Azure AD, and others via Atlassian Access. Access provides enhanced security controls, enterprise-grade authentication features, insights, and more. This has been one of our top requests from enterprise customers.
Am I eligible for unified user management?Unified user management is being rolled out in phases, starting with new Bitbucket Cloud workspaces.
New cloud workspaces: Starting February 5th, 2024, organization admins can add Bitbucket Cloud as a product inside Atlassian Admin and create a Bitbucket workspace. This makes it ideal for customers migrating to Bitbucket Cloud from Bitbucket Server or Data Center, or for existing cloud customers who need to create a new workspace.
One key requirement for Bitbucket Cloud workspaces with unified user management enabled is for your organization to be using Atlassian's centralizeduser management. Read more to find out which management experience you currently have – if you are not currently onboarded to the centralized user management experience, please contact Bitbucket Support.
Existing cloud workspaces: Our next phase, planned for 2025, will include unified user management for existing Bitbucket Cloud workspaces. Please follow our public roadmap for any timing updates.
How to create your Bitbucket workspace in Atlassian Admin1. Navigate to Atlassian Admin inside your cloud organization. 2. Select Add Product, and select Bitbucket.
- Follow the in-product steps to create your new workspace.
- When migrating to Bitbucket Cloud, migrate to an Atlassian admin-enabled workspace that you created using this process.
You can see this support page for more detailed information on how to create a workspace and get started. If you’re looking for a cloud migration trial for Bitbucket Cloud, you can start here.
Need help with your migration or an extended trial?Support:
- To get help figure out if migration is right for you or if you have any product questions, get in touch with our Support team by submitting a ticket here: https://support.atlassian.com/contact/#/.
- To get a cloud migration trial, navigate to this page and get started.
- If you're already in the process of migrating and need help, please raise a support ticket for help with migration planning and execution.
Resources:
- Use this checklist to start planning your migration.
- Get the Bitbucket Cloud migration app to easily migrate your users, code, comments, and pull requests from Bitbucket Server or Data Center to Bitbucket Cloud.
- If you have a complex migration and need help with implementation, connect with an Atlassian Partner.
The post Unified user management is generally available for new Bitbucket Cloud workspaces! appeared first on Bitbucket.
As part of our focus on building features around team scale and performance, we are happy to announce that Bitbucket Pipelines…
The post [New Premium feature] Share pipeline workflow configurations across your repositories appeared first on Bitbucket.
AI tools have taken the world by storm. In April, we announced Atlassian Intelligence to bring the power of AI into…
The post Ship faster by integrating AI into your Bitbucket workflow appeared first on Bitbucket.
If you've been following Bitbucket Cloud's roadmap, you know that we've been heads down focusing on building our product for enterprise…
The post Unified User Management is coming soon to Bitbucket Cloud appeared first on Bitbucket.
We are excited to announce that Bitbucket Pipelines now supports Linux Docker ARM self-hosted runners. The new runner type supports running…
The post Announcing support for Linux ARM Runners in Bitbucket Pipelines appeared first on Bitbucket.
Whether you're the author of a pull request or a code reviewer, it's important to focus on what matters, while making…
The post Finish code reviews faster with improved comment navigation appeared first on Bitbucket.
Atlassian is making changes to how our infrastructure processes Webhook requests originating from our systems. This change is designed to enhance…
The post Updated list of TLS Cipher suites for Webhook requests appeared first on Bitbucket.
We are making git blame feature more discoverable on the Bitbucket Cloud UI. A very useful feature of git, git blame…
The post Improving discoverability of the git blame functionality on Bitbucket Cloud UI appeared first on Bitbucket.
Hello Bitbucket Cloud users,
We recently learned that encrypted copies of Bitbucket’s SSH host keys were included in a data breach of a third-party credential management vendor. The SSH protocol uses host keys to establish the identity of a trusted server for every SSH connection, like when a git pull establishes a SSH connection to Bitbucket Cloud.
In response, Bitbucket issued two new SSH host keys today and will be replacing the current host keys on June 20, 2023. Please review this blog and complete the applicable steps outlined below as soon as possible.
Though we believe the risk of compromise is low, by rotating the host keys proactively we are mitigating future risk should the old host keys be decrypted. If we did not change the host keys it might have been possible in the future for a threat actor to potentially use the old host keys in combination with an already compromised network to trick clients into connecting to and trusting a malicious host.
I want to assure you that a threat actor cannot use the old host keys to directly access your data on Bitbucket Cloud, or to access your private SSH keys.
We understand that rotating host keys can be disruptive. Your security is always our top priority, and we believe that acting proactively is the best approach.
Please read the below for details.
Bala Sathiamurthy, CISO/Head of Security
WHAT'S CHANGING New host keys addedOn May 15, 2023 2300 UTC we added two new host keys using the ECDSA and Ed25519 algorithms:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBPIQmuzMBuKdWeF4+a2sjSSpBK0iqitSQ+5BM9KhpexuGt20JpTVM7u5BDZngncgrqDMbWdxMWWOGtZ9UgbqgZE= bitbucket.orgssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIazEu89wgQZ4bqs3d63QSMzYVa0MuJ2e2gKTKqu+UUO bitbucket.org
The corresponding fingerprints are:
256 SHA256:FC73VB6C4OQLSCrjEayhMp9UMxS97caD/Yyi2bhW/J0 bitbucket.org (ECDSA)256 SHA256:ybgmFkzwOSotHTHLJgHO0QN8L0xErw6vd0VhFA9m3SM bitbucket.org (ED25519)
RSA host key rotationOn June 20, 2023 1700 UTC we will replace our current RSA host key with the following:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDQeJzhupRu0u0cdegZIa8e86EG2qOCsIsD1Xw0xSeiPDlCr7kq97NLmMbpKTX6Esc30NuoqEEHCuc7yWtwp8dI76EEEB1VqY9QJq6vk+aySyboD5QF61I/1WeTwu+deCbgKMGbUijeXhtfbxSxm6JwGrXrhBdofTsbKRUsrN1WoNgUa8uqN1Vx6WAJw1JHPhglEGGHea6QICwJOAr/6mrui/oB7pkaWKHj3z7d1IC4KWLtY47elvjbaTlkN04Kc/5LFEirorGYVbt15kAUlqGM65pk6ZBxtaO3+30LVlORZkxOh+LKL/BvbZ/iRNhItLqNyieoQj/uh/7Iv4uyH/cV/0b4WDSd3DptigWq84lJubb9t/DnZlrJazxyDCulTmKdOR7vs9gMTo+uoIrPSb8ScTtvw65+odKAlBj59dhnVp9zd7QUojOpXlL62Aw56U4oO+FALuevvMjiWeavKhJqlR7i5n9srYcrNV7ttmDw7kf/97P5zauIhxcjX+xHv4M= bitbucket.org
The corresponding RSA key fingerprint is:
3072 SHA256:46OSHA1Rmj8E8ERTC6xkNcmGOw9oFxYr0WF6zWW8l1E bitbucket.org (RSA)
DSA host key removalOn June 20, 2023 1700 UTC we will also remove our DSA host key; this key will stop working entirely.
WHAT YOU NEED TO DOWe highly recommend that you immediately switch to using the newer ECDSA or Ed25519 host keys for each of your SSH clients that connect to bitbucket.org, including other applications such as IDEs and CI/CD build systems. No action is required for your Bitbucket Pipelines builds.
Many SSH clients will switch to one of the new host keys automatically, but you will need to verify this for each connected SSH client. Follow the instructions below to check if your client has automatically switched to the new host keys. If your client did not automatically switch, you will need to follow steps 2 and 3 to manually update your client configuration.
- IDENTIFY IF YOUR CLIENT IS IMPACTEDTo verify which host key your SSH client is using, you can run the following command:
$ ssh git@bitbucket.org host_key_infoYou are using host key with fingerprint:ssh-ed25519 SHA256:ybgmFkzwOSotHTHLJgHO0QN8L0xErw6vd0VhFA9m3SMSee https://bitbucket.org/blog/ssh-host-key-changes for more details.
Do you see either the new ECDSA or Ed25519 host key fingerprint in the output?
- Yes! Your SSH client has switched to the new host keys automatically and no further action is required for this client.
-
No. Proceed to Step 2.
-
CONFIGURE YOUR CLIENT TO TRUST THE NEW HOST KEYSIf neither new fingerprints appear in the output of your OpenSSH (or compatible) client, you can configure the new trusted host keys in the
known_hostsfile with these commands:
$ ssh-keygen -R bitbucket.org && curl https://bitbucket.org/site/ssh >> ~/.ssh/known_hosts
If you are using a different SSH client, you should consult its documentation on how to update its configuration.
- CONFIRM SUCCESSFUL KEY ADDITIONRe-run the commands in Step 1 to confirm that your client now trusts the new host keys.
TROUBLESHOOTING SCENARIOS I've followed the steps, but the new host key fingerprints are not appearing in my client output?Consult your specific SSH client's documentation to ensure the following:
- Your client is not configured to prefer RSA over ECDSA/Ed25519.
- Your client is using the configuration in
~/.ssh/known_hosts; otherwise, you will have to manually reconfigure it to use one or both of the new host keys.
My client only supports RSA host key algorithms.You will need to replace the RSA key on June 20, 2023.
My Bamboo builds are failing to trigger.If your Bamboo instance is configured to use trusted keys your administrator will need to update your configuration to trust the new ECDSA/Ed25519 host keys.
I think my SSH client is broken, what do I do?A small number of clients may have a configuration that attempts to validate the new ECDSA or Ed25519 host keys against the old RSA key, causing the connection to fail. This may include services using low-level libraries like xcrypto/ssh for Go, or libssh2 for C. You can resolve this by updating the configuration of the library to trust the new ECDSA or Ed25519 host keys.
If you still need help after following the step outlined above, you can reach out to our Support team for help by raising a Bitbucket Cloud support ticket at https://support.atlassian.com/contact/#/
I'm using port 443 to run my connection via altssh.bitbucket.org. How do I update my known_hosts file?You can fetch the altssh.bitbucket.org fingerprints and add it to a known_hosts file by running the following:
ssh-keygen -R '[altssh.bitbucket.org]:443' && curl https://bitbucket.org/site/ssh | sed 's/bitbucket.org/[altssh.bitbucket.org]:443/' >> ~/.ssh/known_hosts
FAQ What does a host key do?The SSH protocol uses host keys to establish the identity of a trusted server for every SSH connection, like when a git pull establishes a SSH connection to bitbucket.org.
Why are you rotating the RSA host key?We recently learned that encrypted copies of Bitbucket’s SSH host keys were included in a data breach of a third-party credential management vendor. Though we believe the risk of compromise is low, by rotating the host keys proactively we are mitigating future risk should the old host keys be decrypted. If we did not change the host keys it might have been possible in the future for a threat actor to potentially use the old host keys in combination with an already compromised network to trick clients into connecting to and trusting a malicious host.
A threat actor cannot use the old host keys to directly access your data on Bitbucket Cloud, or to access your private SSH keys.
We understand that rotating host keys can be disruptive. Your security is always our top priority, and we believe that acting proactively is the best approach.
Why aren't you rotating the RSA host key immediately?We do not believe there is an imminent and significant risk to customers. Continuing to allow clients to use a known host key gives users time to carefully and securely establish trust in the new keys.
By taking a measured approach, we are giving users time to transition to the new keys safely and with as little interruption as possible to workflows.
Is any customer data impacted?No, SSH host keys do not secure any data on Bitbucket Cloud.
Are any customer accounts or credentials impacted?No, SSH host keys are not involved in user authentication on Bitbucket Cloud.
Are user SSH keys impacted?No, there is no impact to user SSH keys.
Is Bitbucket Data Center affected?No, there is no impact to Bitbucket Data Center.
Will you be rotating host keys regularly?We do not have plans for future rotations at this time.
Is Git over HTTPS affected?No, only Git over SSH is affected.
You can check whether a specific repository is using SSH by checking its remotes.
If your remote starts with https then you are using Git over HTTPS and you are not affected:
$ git remote -vorigin https://bitbucket.org/test/repository (fetch)origin https://bitbucket.org/test/repository (push)
If your remote starts with git@bitbucket.org then you are using Git over SSH and action may be required (see below):
$ git remote -vorigin git@bitbucket.org:/test/repository.git (fetch)origin git@bitbucket.org:/test/repository.git (push)
How do I know if my SSH connections will be impacted by this?You can check specific clients with our host key information SSH command:
$ ssh git@bitbucket.org host_key_infoYou are using host key with fingerprint:ssh-rsa SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1AWARNING: The host key your client is using will be removed in the near future.Please configure your client to trust a new host key.See https://bitbucket.org/blog/ssh-host-key-changes for more details.
If your client is already using either the ECDSA or Ed25519 host key, then you're all set.
If your client is using either the RSA or DSA host key, then see the steps above to update the configuration of your client.
Do I need to make any changes for Bitbucket Pipelines?No, the trusted host keys provided to your builds will be updated by Atlassian.
Why are you removing support for DSA?The DSA algorithm was deprecated by OpenSSH in 2015. You should update your client configuration to use stronger ECDSA, Ed25519, or RSA encryption algorithms instead.
The post ACTION REQUIRED: Update your Bitbucket Cloud SSH Host Keys appeared first on Bitbucket.
We will be gradually migrating traffic to use new IP addresses for bitbucket.org from August 2023.
The migration is expected to be completed by the end of October.
There will not be any downtime for this migration, and most users will not have to do anything differently because of this migration.
Developers, teams and organizations that use a firewall, access list, security group or other network policy to restrict outgoing SSH access to a particular IP will need to update their rules to permit connections to our new addresses.
The change does not affect the IPs used by Bitbucket to connect to remote servers internet, such as for Webhooks.
Why are we doing this?Bitbucket has seen amazing growth over recent years, with millions of developers and teams using it to build better software.
Continuing our commitment to performance and reliability we'll be making enhancements to our network edge, introducing additional points of presence in the US, Europe, and Asia.
This necessitates the addition of new IP addresses to our IPv4 A and IPv6 AAAA DNS records.
How will this affect you?Most users will not have to do anything special for this change. Your DNS servers should pick up the new IPs within a few minutes, and your systems should start using the new IPs right away. We’ll keep the old IPs running for a few weeks afterward just in case, though.
Firewall considerationsIf you control access to Bitbucket from your network with a firewall, then you may need to update your configuration. Please ensure these new IPs are allowed through your firewall.
New destination IP addresses for bitbucket.org, bitbucket.com, api.bitbucket.org, bitbucket.io, bytebucket.org, altssh.bitbucket.org will be:
- IPv4: 104.192.136.0/21, 185.166.140.0/22
- IPv6: 2401:1d80:3000::/36
These ranges are completely owned and controlled by Atlassian, however, they do include Atlassian products other than Bitbucket. As Bitbucket continues to grow we intend on adding more regions to our edge network, using more IP addresses from these ranges.
Atlassian strongly encourages that the above ranges are permitted through your firewall and recommends against allowing individual IPs. If you need them, here is the full list of individual IPs.
SSH considerationsOur server’s SSH key is not changing, so most SSH clients will continue to work without interruption. However, a small number of users may see a warning similar to this when they push or pull over SSH:
Warning: the RSA host key for 'bitbucket.org' differs from the key for the IP address '18.205.93.1'
The warning message will also tell you which lines in your ~/.ssh/known_hosts need to change. Open that file in your favorite editor, remove or comment out those lines, then retry your push or pull.
Additional resourcesAtlassian Public IP ranges JSON: https://ip-ranges.atlassian.com/ (will be updated with the new addresses as part of the new IPs rollout)
https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html (will be updated with the new addresses as part of the new IPs rollout)
The post New IP addresses for Bitbucket Cloud appeared first on Bitbucket.
We're excited to announce the launch of project-level branch restrictions. This feature is part of our efforts to help teams manage code at scale.
What are branch restrictions and merge settings?Branch restrictions are an essential tool for maintaining the integrity of your codebase. They help you control access to specific branches so only authorized team members can push or merge.
Merge settings are used to maintain code quality. They are a list of conditions, such as approval requirements, successful build status and resolved tasks, that must be met before a pull request can be merged. Branch restrictions ensure that your team follows best practices and maintains code quality when merging changes.
The power of configuring branch restrictions within a projectPreviously, branch restrictions have to be configured individually for each repository. While this provided flexibility, it also meant that maintaining consistency across repositories could become time-consuming and prone to errors. With the introduction of project-level branch permissions and merge settings, you can now apply a standard set of rules and checks to all repositories within a project, making it easier to manage permissions and maintain a consistent workflow.
Here are some key advantages of configuring branch restrictions within a project:
- Streamlined administration: Setting up and managing restrictions and checks for multiple repositories is now more efficient. With project-level configuration, you can establish a consistent set of rules that will save time and reduce the risk of misconfigurations.
- Improved collaboration: By applying the same set of branch restrictions across all repositories, team members can collaborate more efficiently, knowing that they're all following the same processes and best practices.
- Enhanced security: Project-level branch restrictions provide better control over access to your codebase. By assigning permissions at the project level, you can ensure that only authorized team members can push or merge changes, reducing the risk of unauthorized access or unwanted changes.
- Easier onboarding: When bringing new team members on board, it's much simpler to explain and enforce a single set of rules that apply to all repositories within a project. This makes it easier for new members to understand the workflow and adhere to the team's best practices.
- Simplified Auditing: Having a consistent set of branch restrictions across all repositories makes it easier to audit and review your team's workflow. This helps ensure that your team is following best practices and maintaining code quality.
Getting started with project-level branch restrictionsTo start using project-level branch restrictions in Bitbucket, follow these simple steps:
- Navigate to the project in which you would like to apply branch restrictions.
- Select Project settings from the left navigation sidebar.
- Select Branch restrictions under the Workflow heading in the left navigation sidebar.
- Select Add a branch restriction.
- Configure your desired branch permissions and merge settings, then select Save to apply them to all the repositories in the project.
Once configured, the project-level settings will automatically apply to all existing and future repositories within the project. Keep in mind that repository-level settings will override project-level settings, so you can still have unique configurations for specific repositories, if necessary.
The post Maintain code quality at scale with project-level branch restrictions appeared first on Bitbucket.
With support for Bitbucket Server ending in February 2024, we're seeing more and more of our enterprise customers moving their code to the cloud. To enable a smooth migration to cloud for our Bitbucket Server and Data Center customers and to enable our existing cloud customers to scale, we are continuing to build features around security, compliance, and scale in Bitbucket Cloud.
In our last update, we announced improvements to performance and reliability as a result of our move to AWS, full code encryption at rest, and native integration with Snyk, the market leader in developer security. Since then, we've launched features to enable more governance around code, are investing in deeper integrations with the Atlassian platform, and are expanding our CI/CD functionality in Bitbucket Pipelines.
Here's what we've recently launched and some key projects that are in flight.
Security & ComplianceBitbucket Cloud is hosted on the same Atlassian Cloud platform that supports over 250,000 customers around the globe. Our products are built on best-in-class technologies, your data is protected with encryption in transit and at rest, and we provide controls to enforce organization-wide protection such as SAML SSO, and enforced 2FA.
On the product side, we've recently launched several features and controls that you can manage to have more governance around your code.
Audit logs (Shipped): Bitbucket Cloud event logs are now in Atlassian Access so you can view them in one UI along with Jira and Confluence logs. Admins can track down changes in settings or permissions that affect compliance and security teams can use logs to investigate incidents. Learn more
Governance around user invitations (Shipped): With a new user group structure in place, workspace admins now have visibility into all new users added across the workspace and can vet their permissions. We've also added new controls so admins can disable users from sending invitations altogether or allow users to send invitations only to users with specific email domains. Learn more
Granular access tokens (Shipped): REST API tokens are typically tied to a user. However, when teams and user permissions change, user-based tokens can cause workflows to break. We've introduced a new set of API controls that are tied to resources – you can now create tokens at the repo, project or workspace level. Learn more
Enhanced Snyk integration (Shipped): Last year, we launched the native Snyk integration inside Bitbucket Cloud to make it easier for developers to find and fix security vulnerabilities before they ship. The updated version now has a streamlined onboarding process, making it easier and faster to set up. We've also added enterprise controls with IP allowlists so only authorized users can access security reports. Learn more
Signed commits (On the roadmap): This will allow a user to upload a GPG key to Bitbucket and then use that key to verify that they are indeed the author of that commit that they push. This ensures that you can have full control and knowledge over who is committing code to your repositories, keeping all code changes secure and compliant.
Data residency (On the roadmap): For those of you in countries with geo-based regulations around data storage, we realize the importance of giving you the option to be able to choose where we store your data. We are building the foundational pieces of work required to enable this capability and is on our longer-term roadmap.
Admin scalabilityWe are working to make our user provisioning and permissions functionality more scalable for larger teams. These investments will significantly reduce the time needed for admins to manage users and permissions.
Project-level permissions (Shipped): Our current process of managing permissions at the repo or user level. To allow admins to manage permissions at scale, we're revamping our systems to allow permissions management at the project level. Project admins will be able grant or revoke permissions to all repos within a project in one action instead of having to grant permissions to each repo one by one. We are in the testing phase and targeting launch soon. Learn more
Shared user management (In the works): Today, Bitbucket user provisioning is managed within the Bitbucket UI. We know that this has been painful for enterprise admins who manage a large number of users and use multiple Atlassian tools. We're working on integrating Bitbucket into Atlassian Admin so you can manage users across Jira, Confluence, and Bitbucket Cloud in the same UI. And if you use Atlassian Access, you can integrate with identity providers like Okta, Azure AD, and others.
Reliability & performance99.9% uptime SLA's (Shipped): Bitbucket Cloud joined Jira Software, Jira Service Management, and Confluence in offering Premium plan customers financially backed uptime SLAs. This means that if the availability of core Bitbucket Cloud features drops below 99.9% for a given month, you can get a credit on your account. Learn more
Faster repository storage (In the works): We're continuing to work with the Bitbucket Data Center team to move to a new distributed storage model called Bitbucket Mesh. While the primary goal of Mesh is to improve performance, the distributed model lays the foundation for data residency.
Enterprise CI/CDUse your own runners (Shipped): Last year, we launched support for self-hosted Linux runners so you can configure your pipelines to use your own runners behind the firewall. Since then, we've added support for Windows and MacOS runners so now you can manage your builds and tests across all major platforms via Bitbucket Pipelines. For even more flexibility, we launched support for non-containerized runners so you're not bound by container limits on memory or hardware.
Smart caches (Shipped): With our smart caches feature, you can specify dependency versions in a config file and the cache automatically refreshes with the latest version. This means your builds will always use the latest version without spending time downloading new files during the build. Learn more SHIPPED
Configuration at scale (In the works): Maintaining CI/CD configuration across multiple repositories currently requires duplication across repositories. To help you manage configuration at scale and manage compliance across your team, we building functionality to enable sharing CI config across repositories. This means you can maintain a central config file with all the required tests and each repo admin can import the config into their pipeline.
Custom merge checks (On the roadmap): While our current merge checks feature allows you to check off a list of code quality checks before merging code, with custom merge checks, you'll be able to set custom criteria that must pass in order for a pull request to be merged. These checks can be used to enforce code compliance based on your specific organization's policies.
For estimated timelines on some of the upcoming features, check out our public roadmap (updated each quarter)
Migration tooling and resourcesWith support for Bitbucket Server being phased out in Feb 2024, here are some migration resources to help you evaluate and migrate to Bitbucket Cloud.
- Bitbucket Cloud migration app: Easily migrate your users, code, comments, and pull requests from Bitbucket Server or Data Center to Bitbucket Cloud.
- If you have a complex migration, your Atlassian Partner can help.
- [Webinar recording] How Atlassian engineers use Bitbucket Cloud: 6000+ engineers use Bitbucket Cloud at Atlassian. This webinar gives you a glimpse our processes and how we use Bitbucket Cloud internally.
- [Demo] Using Bitbucket Cloud with Jira as part of a DevOps workflow: Open DevOps: Pushing to Production in Bitbucket Pipelines HD
- [Blog] Our experience in migrating CI/CD workflows from Bamboo to Bitbucket Pipelines.
The post Building Bitbucket Cloud for enhanced security, compliance, and scale appeared first on Bitbucket.
Today is a big day for Bitbucket Cloud as we begin rolling out project permissions and permission inheritance to align with Bitbucket Server and Data Center. We will be progressively rolling this out over the next month, so you will see the changes in your workspace before the end of April.
Project permissions has been a long anticipated update for Bitbucket Cloud and represents one of the largest administration improvements for Bitbucket Cloud since we rolled out Workspaces in April 2020. With this release, project admins can grant access to all repositories, old and new, within a project without having to manage each repository individually. We are very excited to share these changes with you.
What is Changing?We followed Bitbucket Server and Data Center as a model for our updates to Bitbucket Cloud's permission management; not only to ensure a seamless transition to the cloud for migrations but also to empower all existing Bitbucket Cloud admins with a more powerful toolset to manage their workspaces.
With the introduction of project permissions, we also implemented permission inheritance, so any permissions set within the project are inherited by any repositories in that project as well. This inheritance extends to the workspace as well so that workspace admin permissions are inherited by all projects.
What are the Benefits?* Scale and Efficiency * Team Autonomy * Better Security
Scale and EfficiencyAll permissions set on a project are inherited by each repository, so when a new repository is added all of the project permissions immediately apply, therefore requiring no permission management on the repository.
As an example, when we rolled out these changes internally for dogfooding we were able to eliminate thousands of repository permissions with dozens of project permissions. Auditing and maintaining a small subset of permissions on projects saves us a lot of precious time.
Team AutonomyBefore project permissions, all repositories existed in a flat structure within a workspace, which means projects provided little more than categorization. Now repositories are structured in a hierarchy, within projects with isolation controls, so that teams can own their own projects within a workspace with full control of their own repositories.
To facilitate better boundaries among projects, we are introducing 2 new roles for projects as well:
- Project Admin allows explicit admin control of all project settings and permissions as well implicit admin control of all repository settings and permissions. This allows workspace admins to delegate control of projects to teams.
- Repository Create grants users or groups the permission to create new repositories within the project.
Better SecurityThe addition of project permissions and inheritance makes the security model much more flexible, while also allowing for a much more secure configuration as well.
As mentioned above, workspace admin permissions are inherited by the project and each repository. This means that workspace admins now have full control of their workspace and access to everything. Workspace admins can no longer be removed from repository permissions, preventing repositories from being managed in the dark.
Because many customers currently have numerous workspace admins to compensate for a lack of delegation to projects, you may find it helpful to evaluate your current number of workspace admins and reduce that number accordingly.
Now that workspace admins have more control over the permissions granted from the workspace to repositories within each project, a few workspace admins should be able to delegate the management of projects to others, giving greater autonomy while following a more manageable workflow.
Finally, we are replacing the repository create permission for a group in a workspace with a new permission to create projects. This means that users can no longer create repositories in any random project, but must instead, have the permission to create a repository within a specific project. Groups can be granted the permission to create new projects but have no access to another team's projects.
This is been a wonderful project (no pun intended) to work on, and we encourage everyone to take full advantage of what project permissions brings to Bitbucket Cloud.
Please refer to our community post for more details on the changes introduced by project permissions and permission inheritance.
The post Project Permissions are available in Bitbucket appeared first on Bitbucket.
Following on from the adoption of the horizontal navigation, the Bitbucket Cloud team is pleased to announce some improvements to the way users move around the product.
You'll begin to see these changes over the next few days, if you haven't already.
What is changing?Single workspace scoped navigationUp until now, the top (global) navigation bar in Bitbucket Cloud was scoped to all workspaces that the user is a member of. For example, the Your work page displayed your relevant pull requests from all workspaces, and the Repositories page displayed a list of repositories from all workspaces you have access to.
Going forward, the top navigation will only show content from the workspace you are currently viewing. Content from other workspaces will no longer be shown. That means that the top navigation menu is scoped to a single workspace to make it easier for the user:
When you want to see content from a different workspace, you will need to switch to that workspace. Use the workspace switcher in the top right corner of your profile menu to switch to a different workspace, or to see a list of all workspaces you have access to.
Besides the workspace switcher, there are a few other ways to switch workspaces:
- Select a direct link to Bitbucket Cloud content (e.g. a bookmark, or an email or Slack notification from Bitbucket Cloud)
- Enter the workspace URL manually in the address bar
- Use search to find and navigate to content from a different workspace (the search bar remains global and across workspaces)
To help users see which workspace they are currently viewing, we've added a workspace indicator to each page.
Additional navigation bar improvementsWe've made a few smaller changes to the top navigation bar as well:
- Direct access to the Pull Requests page
- Workspace members directory is now under the People tab
- Consolidated menu for all settings – if you are a workspace admin, this is where you'll access workspace settings going forward. Reminder: Workspace settings are scoped to the workspace you are viewing.
Why these changes?There were two main reasons driving these changes:
- Alignment with other Atlassian products – Jira and Confluence utilize a concept called sites to help situate users. Scoping the user experience to a single workspace brings Bitbucket closer to that experience.
- Performance improvements – Many views and pages in Bitbucket Cloud had to query content from several workspaces. With all these views scoped to a single workspaces, we are expecting some pages to load faster due to less content needing to show on screen.
The post Improving navigation for Bitbucket users appeared first on Bitbucket.
Caches in Bitbucket Pipelines allows build dependencies and outputs to be stored and reused across many pipeline runs. By reusing work previously done in an initial build, subsequent builds can save time by reducing the need for fetching dependencies or performing expensive computations.
Until today, Bitbucket Pipelines caches have operated much like caches that use time to live (TTL) settings, commonly seen in examples like CDNs and browser caches. Once a pipelines cache is created, it lives for 7 days or until the cache is manually deleted. For many software projects with frequent builds and dependency updates, this type of cache expiry can be suboptimal. Dependencies updated during the course of those 7 days are not stored in the cache so future builds still need to spend time redownloading any new dependencies.
Introducing cache keysToday we are announcing the option to add cache keys to your Pipelines cache definitions. Cache keys provide a way to uniquely identify versions of a cache based on a set of files in your repository. The typical use case would be to define a cache key based on files that define a project's dependencies. When dependencies are updated, the hash of the key files also updates and Pipelines will be able to generate a unique cache version for subsequent builds. As multiple cache versions are able to be retained, future builds using either the old or new dependency set will have a unique cache version to reuse.
Here's an example showing how to define cache keys for a gradle project:
pipelines: default: - step: caches: - gradle script: - ./gradlew assembledefinitions: caches: gradle: key: files: - build.gradle path: ~/.gradle/caches
There can be multiple files listed under the files key. These can refer to any file within your repository. Glob patterns can also be used here to discover multiple key files matching a pattern. This could be useful in a multi-module project for example.
key: files: - build.gradle - "**/build.gradle"
path defines the directory that will be cached and this can include paths outside the repository directory.
Additional documentation on smarter caches with cache keys can be found on our caches documentation page.
Next up: Cache key support for self-hosted runnersToday's release applies to customers running builds on Atlassian infrastructure. We are actively working to add cache key support for our customers that are using runners. You don't need to wait to start using the new YAML syntax. Runner versions without cache key support will simply fallback to the previous TTL cache expiry behaviour. Once we release an update for the self-hosted runner, your builds will start making use of cache keys after the new runner version is installed.
The post Announcing smarter caches in Bitbucket Pipelines appeared first on Bitbucket.
A few months ago we introduced Repository Access Tokens which were the first of the new resource-based authentication methods we are introducing to Bitbucket Cloud. Repository Access Tokens enable a convenient, yet secure way to manage access for users to a specific repository.
While repository access tokens enable you to allow you to control access at a granular level, they are not scalable. To enable you to scale these tokens at the project and workspace level, we are launching project access tokens and workspace access tokens.
Project and Workspace level tokensWith the introduction of Project-scoped and Workspace-scoped Access Tokens, we’ve added another level of flexibility on how you can manage access to your resources. Both these new types of access tokens allow access to repository-based APIs and Git operations to all repositories that fall under the specific project or workspace.
What are the benefits of these new Access Token types?If your Bitbucket workspace has multiple projects and each project has multiple repos within it, these new tokens will apply to all repos under the project or workspace. You don’t need to create a different token for each repo in the workspace. If you have many repos and many projects, these new token types are a more scalable way to manage tokens.
How do I start using these?Both Project and Workspace Access Tokens are part of the Bitbucket Premium plan and will be accessible in the respective Settings page under Access tokens.
Resource-based access tokens are a big step towards better security. For more information, you can visit our Access Tokens help page.
The post Introducing Project and Workspace Access Tokens appeared first on Bitbucket.
We are happy to announce that we are rolling out a completely rebuilt Pull Request (PR) creation experience. Over the last few months we've been building and testing an improved experience when creating a pull request and are excited to finally share it with you.
The main goal of the project was to bring the look and feel of the PR creation process in line with the existing PR viewing process. Both of these pages now share a lot of components, which will ensure they continue to feel seamless as we develop both of them in the future. Additionally, by rebuilding the page we were able to load only the essential information up front which greatly improves page load speeds for large repositories. The average load time to create a PR is approximately 65% faster!
Screenshot of the new PR Create PageHighlightsThe process of creating a pull request is central to a developer's workflow. Here are a few highlights we want to call out:
- The new page has a much faster load time with more information fetched after the initial page load. This performance improvement has the largest impact for large repositories with lots of users.
- The description editor, diff, reviewer selector, and commit list have been updated to match the rest of the pull request experience.
Have Feedback?If you have feedback for us please share it by clicking the "Give feedback" menu item in the top right drop down and filling out the subsequent form. We look forward to hearing from you.
The post Announcing a Rebuilt Pull Request Create Page appeared first on Bitbucket.
We are excited to announce that Bitbucket Cloud event logs now can be tracked in Atlassian Access. With the Atlassian Access audit logs feature, organization admins will ultimately be able to trace critical Bitbucket user activity, including who, when, and what actions were performed.
As part of Atlassian’s cloud-first strategy, Atlassian is investing in building more and more enterprise capabilities into Bitbucket Cloud to ensure a seamless experience for customers looking to migrate from Bitbucket Server to Cloud. This release of audit logs enables admins to have governance around user actions in Bitbucket Cloud. Security teams can use audit logs to investigate incidents, and admins can use them to track down changes in settings or permissions that affect compliance.
Here's how to enable them for your workspace.
Connect your Bitbucket workspace to Atlassian AdminThese new audit logs are available to Bitbucket customers via Atlassian Access. If you do not already have an Atlassian Access subscription, you can follow the directions here to start a free 30-day trial.
To enable audit logging, start by linking your Bitbucket workspace(s) to your Atlassian organization in Atlassian Admin. This can be done by following the instructions below.
To link a Bitbucket workspace to your organization1. Go to admin.atlassian.com. Select your organization if you have more than one. 2. Select Products > … > Link products. 3. From the Select products screen, select a Bitbucket workspace you want to link. 4. Review and confirm the workspace to be linked. 5. Repeat the process for each workspace you want to link.
Once you link a workspace to an organization, you can't unlink it or transfer it to another organization.
Accessing audit logsThere are two ways to access audit logs, via API and the Atlassian Access UI.
Security teams can use the API to investigate incidents, as well as to import logs into an SIEM tool like Splunk for further monitoring and analysis. More details on the organization audit log API can be found here.
Organization admins can use the UI to search through events to track down changes in settings or permissions that affect compliance, who made them, and when, with the ability to filter by location, actor, or event, as well as to export to CSV.
More information on the organization audit log feature can be found here.
What's next?This release covers our first iteration of events, we will continue to roll out additional events over the next weeks to increase coverage. Read more about the events Bitbucket logs here.
Next, we will be tackling more specific user activity, including git activity (for example, clones and commits), to increase coverage of common actions in the product.
The post Bitbucket audit logs are now available in Atlassian Access appeared first on Bitbucket.
As part of our ongoing commitment to meeting the Security & Compliance needs of our customers, Bitbucket Cloud is introducing the…
The post Access Your Bitbucket Cloud Repositories More Securely With Resource Scoped Access Tokens. appeared first on Bitbucket.
Parallel steps in Bitbucket Pipelines allow you to build and test faster by running a set of steps at the same…
The post Bitbucket pipelines: Failing parallel builds fast appeared first on Bitbucket.
We are excited to announce some big changes for Bitbucket Cloud invitations. Over the next week we will begin progressively rolling…
The post Launching increased transparency and control for workspace invitations appeared first on Bitbucket.
We are happy to announce that we've made improvements to our repository size limits and how those size limits are maintained…
The post Updated repository size limits and automatic garbage collection appeared first on Bitbucket.
This post is authored by Marco Morales, Partner Solutions Architect, and Sarah Conway, Director of Partner Marketing, at Snyk. We're…
The post Introducing the New Snyk App for Bitbucket Cloud appeared first on Bitbucket.
The Bitbucket Cloud (BCLOUD) project is an invaluable source of customer-requested product features, enhancements, and suggestions. As Bitbucket Cloud has continued…
The post We’re listening! Leveling up how we gather, review, and respond to product feedback. appeared first on Bitbucket.
We are happy to announce that as of October 4, 2022, Bitbucket Cloud is joining our flagship cloud products Jira Software,…
The post Announcing financially backed uptime SLA’s for Premium plan customers appeared first on Bitbucket.
We are introducing a new premium merge condition in the repository settings For repositories that have enabled the “Reset approvals when…
The post Preserving pull request approvals appeared first on Bitbucket.
We are happy to announce that Bitbucket Pipelines now supports non-containerized Linux Shell self-hosted runners. This is currently in beta. You…
The post Announcing the Open Beta for Linux Shell Runners in Bitbucket Pipelines appeared first on Bitbucket.
Over the last few weeks, we’ve launched several new features like support for Docker BuildKit, the ability to set default PR…
The post Bitbucket Cloud product updates (August 2022) appeared first on Bitbucket.
We are introducing a change to the pull request merge checks that will make them more reliable. Specifically, we will no…
The post More reliable merge checks appeared first on Bitbucket.
There are multiple ways to create a task on a pull request. They can be added from the sidebar, top-level pull…
The post Default Pull Request Tasks appeared first on Bitbucket.
Learn more about Bitbucket Cloud and start planning your migration.
The post Bitbucket Cloud migration Q&A appeared first on Bitbucket.
We are happy to announce that one of the top voted features for Bitbucket Pipelines, Docker BuildKit is now available. You…
The post Announcing support for Docker BuildKit in Bitbucket Pipelines appeared first on Bitbucket.
Bitbucket Cloud is making changes to pull request diff functionality that will improve diff performance, particularly on complex diffs. We are…
The post Improving performance on complex diffs appeared first on Bitbucket.
We are happy to announce that Bitbucket Pipelines now supports self-hosted runners on Windows. You can create a self-hosted runner and…
The post Announcing support for Windows runners in Bitbucket Pipelines appeared first on Bitbucket.
We're changing who can delete snippet comments. Our goal is to give users more control over content attached to their snippets.…
The post Changes to deleting snippet comments appeared first on Bitbucket.
One of my teammates calls change management the "eat your vegetables of ITSM." Just like eating veggies is important for getting…
The post A modern approach to change management with Bitbucket Cloud and Jira Service Management appeared first on Bitbucket.
We are happy to announce that Bitbucket Pipelines now supports macOS self-hosted runners. This is currently in beta. You can now…
The post Announcing the beta for macOS Runners in Bitbucket Pipelines appeared first on Bitbucket.
Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is…
The post Git push size limits are coming to Bitbucket Cloud starting April 4th, 2022 appeared first on Bitbucket.
We are excited to announce that improvements to the Branch page will be available in Bitbucket Cloud in the coming weeks!…
The post Introducing Bitbucket’s redesigned Branch page appeared first on Bitbucket.
We're changing the way we manage suggestions for new Bitbucket features in our public issue tracker. Our aim is to improve…
The post Update on how to submit product feedback appeared first on Bitbucket.
After Bitbucket's platform migration to AWS back in August 2021, all repository source code and product data was encrypted at rest.…
The post Bitbucket Cloud is now encrypted at rest appeared first on Bitbucket.
Recently, we introduced support for default values in custom pipeline variables. Today, we're happy to announce the ability to make pipeline…
The post Predefine values of custom pipeline variables appeared first on Bitbucket.
Workspace admins can now set the following project-level settings: default reviewers, access keys, branching model, and merge strategies. These project settings…
The post Project Settings are now available in Bitbucket Cloud! appeared first on Bitbucket.
By now, you’re probably assessing your level of exposure — or are in the middle of remediating — the recently disclosed…
The post Log4Shell fix with the Bitbucket Cloud and Snyk integration appeared first on Bitbucket.
Bitbucket Pipelines provides a feature that enables you to configure memory in Docker services (learn more on that here).
We have related highly voted suggestion where customers would like to configure multiple Docker services, each with different memory configurations.
Here’s a working example of how you can set memory limits to multiple Docker services and use the appropriate service depending on the step requirements.
``` definitions: services: docker: memory: 512 docker-with-more-memory: memory: 2048 type: docker docker-with-large-memory: memory: 5120 type: docker
pipelines: custom: pipeline1: - step: services: [docker] script: - echo "Docker service with 512 MB memory" pipeline2: - step: services: [docker-with-more-memory] script: - echo "Docker service with 2048 MB memory" pipeline3: - step: services: [docker-with-large-memory] size: 2x script: - echo "Docker service with 5120 MB memory"
``` The post Configuring multiple Docker services with different memory limits appeared first on Bitbucket.
On 8th December 2021, new IP addresses were provisioned for our build infrastructure, allowing for improved resiliency in our Kubernetes infrastructure. These addresses will become active in the next six weeks.
The new IP addresses are:
- 3.216.235.48/32
- 34.231.96.243/32
- 44.199.3.254/32
- 174.129.205.191/32
- 44.199.127.226/32
- 44.199.45.64/32
- 3.221.151.112/32
- 52.205.184.192/32
- 52.72.137.240/32
Refer to What are the Bitbucket Cloud IP addresses I should use to configure my corporate firewall? for the full listing of outbound IPs.
The post Infrastructure Changes – New Outbound IP Addresses appeared first on Bitbucket.
Bitbucket Pipelines provides a caching feature that provides the ability to cache external build dependencies and directories e.g. 3rd-party libraries. This means faster builds and fewer consumed build minutes.
However, caches currently live for 7 days and are invalidated at the end of that period. And updates to build dependencies do not cause the cache to be refreshed which means that builds can sometimes use old versions of dependencies, leading to downstream errors. We have this highly voted suggestion where customers are looking for an option to invalidate and refresh the cache automatically whenever there is a change in the build dependency.
In this blog post, we are sharing a solution that can help to invalidate and refresh the cache automatically whenever there is a change in the build dependency.
Here’s how it works:
atlassian/bitbucket-clear-cache Pipe
We use the atlassian/bitbucket-clear-cache pipe to delete the cache in the pipeline. Here’s the yaml for this pipe.
``` pipe: atlassian/bitbucket-clear-cache:3.1.1 variables: BITBUCKET_USERNAME: $BITBUCKET_USERNAME BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD CACHES: [ "node"]
```
Changesets condition
Next, the condition changeset is used to execute a step only if there is a change in a specific file. If not, the step will be skipped.
We will add the changeset condition to indicate the file to be verified for the changes before actually deleting the cache. The structure in your YAML file will be something like this:
``` pipelines: default: - step: name: delete cache if changes in the build dependencies script: - pipe: atlassian/bitbucket-clear-cache:3.1.1 variables: BITBUCKET_USERNAME: $BITBUCKET_USER_NAME BITBUCKET_APP_PASSWORD: $BITBUCKET_APP_PASSWORD CACHES: ["node"] condition: changesets: includePaths: - package.json - step: name: build and create/reuse the cache caches: - node script: - npm install - npm test
```
That’s it. This process will check your dependencies for changes, and if there is a change, it will delete the existing cache and create a new cache so your builds are always using the most current versions of dependencies.
Limitations: * Caches are currently global and shared across multiple branches. When the cache is invalidated it will clear the cache for all branches, until it is cached again. * Changesets only find files in the last commit, so if multiple commits are pushed, only the last one will be checked for the includePaths section.
Watch and share your feedback in BCLOUD-16314 feature request as we will look into implementing out of the box support and better caching / invalidation strategies in the future.
The post Automatically refresh caches when build dependencies are updated appeared first on Bitbucket.
Bitbucket Cloud is getting a makeover!
We are joining Jira and Confluence Cloud and moving our global navigation from a vertical bar along the left side to a horizontal bar displayed along the top of Bitbucket Cloud. This update is a huge improvement for our users in terms of findability and ease of use, and it also provides a consistent user experience for our customers using other Atlassian products.
Ready to try the new horizontal navigation bar? Keep an eye out for the feature in Labs, arriving November 17 2021. Soon after, the horizontal navigation bar will become the default view. You can revert to the vertical navigation bar by disabling horizontal navigation in Labs.
To improve access to your most frequently used items, we've moved Pull Requests, Issues, and Snippets to the dropdown menu under More.
We've updated the global 'Create' menu to show the most frequently used global and contextual 'create' actions.
That's not all!
We've also improved the search experience to allow Bitbucket users to search their instances of Confluence and Jira. This means that Atlassian users can seamlessly navigate between different products using the new search bar.
The post Help us welcome Horizontal Navigation to Bitbucket Cloud! appeared first on Bitbucket.
In July and August of this year, I revealed to our community for the first time that Bitbucket Cloud was engaged in a project to migrate to a new platform. As I wrote in July:
``` For over a decade, the majority of Bitbucket's services have been hosted in a data center. While this has served us well for many years, operating a data center comes with significant overhead as well as risk. For example, when we have had unexpected capacity issues (e.g. hardware failures or unplanned outages in upstream services), we have been limited by the physical servers we had available, impacting our time to recovery.
Over the past year, we have been on a journey to migrate all of Bitbucket Cloud to Micros, Atlassian's internal cloud platform based on AWS. This is truly a quantum leap for Bitbucket Cloud and will resolve many reliability issues including the one described above and more. ```
I am thrilled to announce that, in late August, we officially completed this project and Bitbucket Cloud has been operating in AWS, data center-free for over 2 months.
So how does this benefit our customers?
- Reliability. Bitbucket's infrastructure has never been more resilient and scalable.
- We have had zero major reliability incidents (i.e. outages or degraded performance) since the completion of the migration.
- Over the past two months since completing the migration, our volume of weekly support cases related to reliability has decreased 93%.
- Security. Bitbucket is more secure today than ever before.
- Our cloud storage volumes providing our web services access to customer source code are now encrypted at rest.
- Running on Atlassian's cloud platform (Micros) allows us to leverage security best practices and policies enforced platform-wide, such as resource isolation via security groups, regular OS scanning for known vulnerabilities, regular data backups, and more.
- Removing data center operations from our teams’ responsibilities eliminates an entire class of security risk: servers, drives, network interfaces, and other hardware that needed to be regularly updated and protected.
- Performance. Thanks to major investments in Bitbucket's architecture to reduce our services’ sensitivity to file system latency, our web response times across our core capabilities today are on average 55% faster than back at the start of 2020.
This is one of the most technically complex projects we've ever tackled as a team. The following are just a few stats to convey the scale of this accomplishment:
- We migrated over 50 million repositories to our new cloud storage backend.
- Additionally, we replicated and moved all other data stores with traffic totaling over 200,000 queries per second to AWS.
- Our services regularly handle over a billion daily transactions which we redirected transparently to elastic compute resources in AWS with zero downtime.
I couldn't be prouder of the many engineers—both within the Bitbucket Cloud team and across the multiple Atlassian platform teams who supported us—who made this migration possible. On that note, stay tuned for a more in-depth engineering blog post in the coming weeks wherein we will share some highlights covering the work we did to achieve this, challenges we faced, and lessons learned along the way.
The post Bitbucket Cloud has landed in AWS appeared first on Bitbucket.
We are excited to announce the launch of the Bitbucket Cloud Migration Assistant, an Atlassian-supported app built to help Bitbucket Server customers automate the migration process from Bitbucket Server to Bitbucket Cloud.
If you are considering a move to Bitbucket Cloud, this is the easiest way to get started.
Download the app from the Atlassian marketplace.
What does the Bitbucket cloud migration assistant do? You can automatically migrate:
- Your projects and repositories
- All pull request diffs and metadata (comments, users, authors, reviewers)
- Users, including inactive users so past comments, authors, and reviewer statuses are preserved.
Note: The app does not migrate user permissions and groups. These will need to be set after the migration is complete.
Scroll down for a demo of how it works.
Migration resources * Download link * Plan your Bitbucket Server to Cloud migration * Need to migrate other Atlassian products? Learn more about all the latest cloud migration tools available here: Cloud Migration Tooling
Learn about Bitbucket Cloud Bitbucket Cloud is part of the Atlassian Open DevOps suite of tools. Connect Bitbucket Cloud to Jira Software, Confluence, Opsgenie and best of breed partners like Snyk, Sentry, Datadog, and more to build your DevOps stack.
Here are some of the features you'll find in Bitbucket Cloud:
- Native Jira integration: View and comment on your Jira issues directly from your Bitbucket dashboard to keep work moving without switching apps. And when you include issue keys in your commits, your team can track code changes and deployments within Jira. Learn more | View Demo
- Built-in CI/CD: Bitbucket Pipelines is an integrated CI/CD tool in Bitbucket Cloud. This means easy setup and no servers to manage (unless you want to use your own runners). Learn more | View Demo
- DevSecOps integrations: Bitbucket Cloud has out-of-the-box integration with Snyk or you can integrate with other providers such as SonarSource, Bridgecrew, Sonatype, and others via the Bitbucket marketplace.
- Enterprise-grade security features like IP allowlisting, 2FA, and advanced user permission controls are part of Bitbucket Premium plan.
- Great features on the horizon: We're building several features such as audit logs, project-level settings, Windows and MacOS runner support, and a lot more. View the public roadmap.
To get started, sign up for free with Bitbucket Cloud and download the Bitbucket migration assistant.
View demo
The post Announcing the Bitbucket Cloud Migration Assistant appeared first on Bitbucket.
Bitbucket Pipelines provides a Docker caching feature that can help improve build times. However, the limitation is that only compressed caches under 1GB are saved and can be used. In this blog, we outline a process showing how you can use compressed caches that are larger than 1GB.
With Docker versions >= 19.03, you can use the BuildKit feature. With BuildKit, you don’t need to keep the cache locally before building the Docker image since it caches each build layer in your image registry. Then, when you build the Docker image, each layer is downloaded as needed during the build.
However, you cannot enable BuildKit for the default Docker service in Bitbucket Pipelines. To enable BuildKit, you'll need to use a self-hosted runner to execute your builds. With a self-hosted runner, you can specify your step to use a custom 'dind', which allows you to use the 'buildkit' feature. With the 'buildkit' feature, turn on the inline layer caching using the BUILDKIT_INLINE_CACHE build argument and use --cache-from while building the image using remote caching.
Here’s how it works:
Define a custom 'dind' First, define a docker service with docker in the docker image (dind). Since the current docker:dind is already enabled in buildkit by default, you can just use it (as shown below)
``` definitions: services: docker: image: docker:dind
```
Then in your Pipeline step, enable BuildKit and turn on inline layer caching using the BUILDKIT_INLINE_CACHE build argument and use --cache-from while building the image using remote caching.
Enable buildkit with DOCKER_BUILDKIT env var and build the image using remote caching
``` pipelines: default: - step: name: Step 1 runs-on: self.hosted script: - export DOCKER_BUILDKIT=1 - docker build \ --build-arg BUILDKIT_INLINE_CACHE=1 \ --cache-from $IMAGE_NAME:$IMAGE_TAG \ -t $IMAGE_NAME:$IMAGE_TAG . - docker push $IMAGE_NAME:$IMAGE_TAG services: - docker
definitions: services: docker: image: docker:dind
```
Once you’ve configured self-hosted runner using a Docker service with the default BuildKit option enabled, your build times will be faster with Docker remote caching as the Docker image build process will use the cached layers instead of building them everytime from scratch.
The post Faster CI Builds with Docker Remote Caching appeared first on Bitbucket.