Scheduled pipelines now available in Bitbucket Pipelines

By on August 16, 2017

Bitbucket Pipelines makes it quick and easy to get fast feedback when changes are committed. However, there are many use cases where builds need to be run on both changes to the code base and on a regular schedule. Some examples include:

We’re excited to announce that you can now run pipelines on a schedule. This is another highly requested feature by our users. Creating a schedule is easy. Just define a custom pipeline in your bitbucket-pipelines.yml configuration. Then create a schedule for a branch from the main Pipelines view.

Pipelines can be configured to run on an hourly, daily or weekly schedule.

Happy building!

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

4 features in 4 weeks: here’s what’s new in Bitbucket Cloud

By on July 27, 2017

Machines are cheap, but your time isn’t. Throughout your day, every tedious task adds up. Individually reverting each commit in the command line after a mistake, searching forever for an important part of your code during a review, or waiting on a build to finish can be culprits that contribute to an unproductive day.

We want to make your job easier, which means helping you manage your time and productivity. In the past month we’ve been busy releasing 4 new features that are going to get you out of the office that much sooner.

Revert merged pull requests:

At some point, we’ve all merged code we wish we could take back. Luckily, git revert has always allowed you to revert mistakes in the command line. But if this mistake you’re reverting involves a pull request, reverting this in the UI is much easier, and necessary for quick access.

Today we’re adding the ability to revert a pull request that was merged on a Git repository in Bitbucket’s user interface. Instead of automatically reverting all commits (which can lose any changes that’ve been made since that merge), a new pull request will be created that has to go through an approval process. That revert pull request will suggest all recent approvers (plus anyone else you would like to add), and help ensure that all proper merge checks are met prior to reverting. This will keep all team members in the loop and keep all the changes made by any team member. Check out revert merged pull request documentation here.

Commit API

Our most popular add-ons like AWS CodeDeploy make it easier for developers to complete their workflow within Bitbucket, save time and increase productivity. Howeverour add-ons were missing the ability to look deeper into your commits. Without this, certain processes like creating files were manual, and therefore more time consuming. We want to empower our users with the integrations they need so we created a commit API to help with this. This API allows developers to integrate Bitbucket in to external services and retrieve information normally accessed in the command line or commit:

By enabling add-on developers with the commit API, we’ve opened up more data to add-ons that give you more possibilities with them. As a result, we have several 3rd parties working on new integrations. Keep a look out for a new Jenkins integration and more that are using the commit API and check out the API if you are interested in making an add-on.

Syntax highlighting in code search

Bitbucket Cloud launched a Beta of our #1 highest voted feature in May: code search. Our code aware search saves you time combing through usage results with a semantic search that ranks definitions first over usages or variables names. It first launched with viewing search results in plain text, and combing through a sea of unformatted text results can be tedious and can take longer to find what you’re looking for.

In this next iteration of code search, we wanted to simplify search results so they are easily scannable with syntax highlighting in our code aware search. This helps when reading and reviewing code because you can track the most important parts, without having to go through it with a fine-tooth comb. Check out code aware search documentation here.



Dependency Caching in Bitbucket Pipelines

Bitbucket Pipelines is our built-in continuous delivery service that runs builds in Docker containers. This gives you the benefit of your build scripts executing much sooner than running them on Virtual Machines, and ultimately means builds aren’t waiting in a queue. With this model, we noticed faster build times than a CI tool that requires a server, but still not as fast as we’d like. Between builds, dependencies needed to be downloaded each time, which tacked on time per build. Not awesome.

By adding support for caching between builds in Pipelines, we saw build times reduced by up to 50%. This addition should have you waiting less on build times. To get you started, we have pre-defined caches for popular build tools or you can create a custom cache here. Check out the caching dependencies documentation here.

dependency caching

Try Bitbucket’s newest features

If you’re ready to start using any of these features, sign up for a Bitbucket Cloud account and take them for a spin. Already a Bitbucket customer? refer to the feature documentation to get going.

Get started, it’s free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

Bitbucket Server 5.2: Compliance meets DevOps

By on July 18, 2017

Version control is at the heart of every development team’s process. The version control tooling and technology you select not only dictate how you interact with your team, but can also hold you back from making improvements to your workflow. For example, teams looking to adopt DevOps practices can be especially frustrated with the lack of tooling options if they are also facing organization compliance requirements (e.g. audit trails, mandated workflows, and permission structures). To comply you may get stuck using older homegrown solutions or must continue following inefficient development patterns.

Bitbucket Server & Data Center bring the best of both worlds – Git repository management focused on speed, collaboration, and quality with the security, traceability, and scale required to fulfill meaty compliance rules. Today we’re introducing project level administration, an additional tool for ensuring compliance regulations can be met without the burden of constant monitoring by administrators.

Keep reading to learn more about project level administration and an update to Bitbucket Data Center smart mirroring in 5.2.

Download Bitbucket Server 5.2

Project level administration

Bitbucket Server is built for professional software teams, providing more ways to customize and secure your workflows than other Git management tools. For any repository, administrators can configure the branching model, the type of merge strategy used for pull requests, mandate that all commits be GPG signed and/or pushed only by the commit author, restrict branch access, and more. All of which play a role in ensuring compliance requirements are met without the team having to worry about it.

Until today things like hooks, branch permissions and model, and pull request merge checks had to be configured each time a new repository was created. In organizations with teams that create hundreds or thousands of repositories, this leads to wasted time or security holes by granting repository admin access to folks who originally may not have needed it. With the introduction of project level administration, these settings can now be applied to all the repositories in a project at once.

Hooks Project Settings

Project level administration works in much of the same way that repository settings do. Any user who’s been granted project level administration rights can edit the settings for the project, which will apply to all the repositories stored within. New repositories created will instantly inherit settings from the project level. However, if a repository has unique requirements, the repo administrator can modify specific settings by overriding the project level configuration. For more information on project level administration, see our release notes.

Merge Checks Repo Settings

Smart mirror push proxy

Smart mirrors in Bitbucket Data Center help global teams speed up pull operations in high-latency and low-bandwidth environments. These read-only copies of repositories stay updated automatically and inherit all the rules and permissions configured on the master server. Previously, continuous integration servers and developers using mirrors needed to maintain 2 URLs, one for fetching from the mirror and the other for pushing to the primary server. In Bitbucket Data Center 5.2, we’re introducing push proxying, which combines both operations into a single HTTP or SSH URL – one less thing to worry about in your day to day development activities.

Compliance meets DevOps

Adopting DevOps practices while maintaining a secure, traceable, and scalable development environment is possible. The tooling you select shouldn’t hold you back from making positive changes, it should enable them. Bitbucket Server 5.2 can help your team take advantage of the best DevOps has to offer while complying with organizational policies. Create a workflow that works for your team minus the auditing and compliance headaches. It’s a win-win all around.

Download Bitbucket Server 5.2

Confessions of a Git wallflower, and other stories about Bitbucket

By on June 30, 2017

This post comes from Abhishek Sharma, a Masters of Science student at the University of Southampton and member of Bitbucket’s Student Amabassador team.

“Code collaboration on steroids” — this is how Atlassian describe Bitbucket on their site. And this is exactly what I experienced first-hand when I lost my Git virginity after being introduced to Bitbucket in September last year. I’ll tell you the story in a moment, but if you’d prefer to just cut to the chase…

Anyone can use Bitbucket for free. But university students and staff can upgrade to the premium offering at no extra charge (take that, student debt!). There’s a party going on over here, and you’re all invited.

So. On with my story.

For one of my Master of Science modules in the first semester, we were tasked with a group project. I know, I know… the dreaded group project. We had to create a trading agent that could perform the bidding strategy of advertising networks in the AdX TAC (a virtual platform for simulating an ad exchange marketplace) by automatically placing ad bids that would ensure the largest revenue and profits are generated by winning as many campaigns as possible – preferably big campaigns. We also had to minimise the costs incurred to fulfill said campaigns.

My group’s agent would then compete with 24 other agents in a 7-hour trading competition where, despite our best efforts, it would end up placing 14th. Simply because we opted for a rational strategy instead of exploiting the randomness factor in the competition… but that is a discussion better left for another day.

So, after an endless amount of reading and understanding what it is we were required to do, one of the members (who also happens to be one of the most hard-working people I’ve had the pleasure of befriending in my short life so far) of our team recommended we use Bitbucket to manage our project.

Now, at the time, I was only familiar with GitHub and thought of it as just a means for finding similar projects to whatever coding assignment I may be working on at that point. Creating an actual repository and collaborating with others on a big project like this was the equivalent of walking into a department mixer where everyone knows each other’s names – except you.

Not to mention that I had never worked on a group coding project before, let alone use a Version Control System (VCS) to manage it. Not surprisingly, the whole situation so overwhelmed by my brain that I started second-guess my coding skills and even my decision to pursue a MSc in the first place. My teammates were doing the Git equivalent of drinking me under the table.

Thankfully, however, they were kind and patient enough to put up with my inexperience. They answered all the stupid questions I asked regarding Bitbucket, Git, and the project in general – thus helping me realise the importance of Git in the process.

Once the project was over and submitted, I realised just how insignificant my contributions had been thanks to my lack of experience with Git. It was around this point when I strolled across the Bitbucket tutorials. Through them, I finally learnt how to create a repository via the Git terminal rather than creating one directly from the Bitbucket site. Yes: despite having an undergraduate degree in software engineering, I had so little exposure to Git that even being able to use Git Bash to do simple things like clone, pull, and push commits was mind-blowing for me.

Fast-forward to today, and the tutorials have made me so confident using Git that the first step I take now before embarking on any coding venture is to create a repository. Not only does this allow me to make my projects available to potential collaborators, it also helps me direct potential employers to the coding projects I have worked on (or am currently working on). It’s nice to be able to prove that I truly possess the technical skills I claim to have on my resume.

Although it is through Bitbucket that I learnt (and am currently in the process of mastering) the wonders of Git, most of my projects are currently based on GitHub right now. But I’ve already started migrating these to Bitbucket and make that my primary tool for project management.

Why, you ask? Well, it’s simple. The free version of Bitbucket offers loads more features to play with than the free version of GitHub.

For example, Bitbucket have recently introduced a feature called code-aware search, which is an easy way to comb through large repositories and code bases. As a bonus, it forces you to get into the good habit of writing good, reusable code so that the semantic search algorithm used by the feature can return results in a ranked format. From what I know, GitHub does not offer this (or maybe you have pay for it).

Also, Bitbucket offers free academic licenses for students and professors, which lets you create unlimited repositories (both public and private) along with the ability to add an unlimited amount of collaborators. Seriously. It’s free, as long as you are a student at one of the academic institutions that Bitbucket offers these licenses to. And if your school isn’t on their list yet, you can get on the list here.

So that’s my story. I’d spent my entire undergrad career knowing that there’s this massive party called Git that everybody was going to, but too shy (and/or) busy to get myself invited to it. Thank you, Bitbucket, for pulling me in.


Calling all university students and professors! Learn how Bitbucket’s free academic license program can help your next project or class.

Git educated (see what we did there?)


Faster builds with dependency caching

By on June 27, 2017

One of the key principles behind the design of Pipelines was quick developer feedback on changes committed. After all, machines are cheap but your developers’ time isn’t. This principle influenced how we chose to price pipelines to provide unlimited concurrency, so builds aren’t waiting in a queue. Running builds in Docker containers also means your build scripts start executing much sooner than running them on VMs.

With most languages, builds start by downloading dependencies, accounting for a significant time of each build. Between each build, dependencies seldom change and when they do, it is usually incremental. Builds can be faster if dependencies don‘t need to be downloaded each time.

Today, we are excited to announce that Pipelines supports caching between builds. For early adopters in our Alpha group, we have seen builds reduced by up to 50% in build time (and build minutes)!

Adding a cache is simple. Here’s an example for adding a cache for node_modules.

image: node:8
    - step:
          - node
          - npm install
          - npm test

We’ve pre-defined caches for several popular build tools. If your build tool doesn’t have a pre-defined cache, you can still define a custom cache in your bitbucket-pipelines.yml file. Caches are per repository and can be shared between your pipelines.

With this addition, we hope your developers are waiting less and coding more!

Enabled caching already? Tell us on Twitter @Bitbucket how much it has shaved off your build time.

New outbound IP addresses for webhooks

By on June 21, 2017

Bitbucket webhooks are used by teams every day to test, analyze, deploy, and distribute great software to millions of people.

In a few weeks, we will be making a change to our network configuration that results in these services routing through different IP addresses. We plan to make this change no earlier than Monday July 10th.

If you’re using webhooks and have firewall rules to allow Bitbucket to communicate with your servers, you’ll need to add the new IPs to your rules before Monday July 10th.

The current source IP address range is:

The new source IP addresses will be:

As always, you can consult our documentation for the current list of supported IPs for webhooks.

New in Bitbucket Server 5.1: Signed commits, PR deletion, and more

By on June 7, 2017

Last month we announced the beginning of our Bitbucket Server & DC 5.x series with an enhanced focus on helping our customers achieve DevOps success. Today we’re taking aim at the management side of DevOps by making the administration of your development toolset easier with Bitbucket Server and Data Center 5.1.

Keep reading to learn about GPG signed commits, pull request deletion, and other new features in 5.1.

Download Bitbucket Server 5.1

GPG signed commits

For those practicing DevOps, Git has become the preferred version control system for its flexibility and speed. This flexibility is powerful but also extremely hard to control without a tool like Bitbucket. For organizations who need to run a tight ship (e.g. adhering to regulatory requirements), Bitbucket’s permissions, merge restrictions, and hooks help immensely. Today we’re adding an additional security measure with the Verify Commit Signature hook, which rejects all commits that are not signed with a GPG public key. Coupling this with the committer verification hook, you can be assured that all the commits in Bitbucket are valid and secure. To learn more about toggling hooks on and off, see our repository hooks guide.

Pull request deletion

Next up is a highly requested improvement to our pull request workflow, the ability to delete them. Have you ever created a pull request by mistake? Or found a pull request to be obsolete? In Bitbucket Server 5.1, irrelevant pull requests can now be deleted instead of declined, leaving your PR history nice and clean. Pull request deletion is now enabled by default for pull request authors and repository administrators.

Disable Pull Request

Search improvements

Last year we brought code search to Bitbucket Server, allowing teams to search for code across all repositories stored in Bitbucket.

For teams making extensive use of forks, the process of building an index for search can use a fair amount of disk space. In Bitbucket Server 5.1, we’re introducing a way for administrators to keep search disk space under control by limiting what actually gets indexed. For example, you can restrict the index process to exclude synced forks, which reduces disk space and provides refined search results.

In addition, we’ve also updated our Elasticsearch guides for Data Center customers, providing more guidance on deploying an Elasticsearch instance.

Download Bitbucket Server 5.1

One more thing: In Bitbucket Server 5.1, we’re laying the foundation for project level settings, allowing project admins to configure items, such as branching model and permissions, across all repositories in a project. To learn more about project level settings and other improvements and bug fixes in 5.1, see our release notes.

Speed up your builds with Pipelines command duration

By on May 31, 2017

Every team wants fast feedback from their CI system, which is why we’ve just added command durations to all Pipelines builds. Knowing which parts of your build take the longest gives your team the information to speed up your build and shorten your team’s feedback loop.

You can now see the duration for each command directly in the Pipelines log viewer. We’ve picked a consistent duration format for quick scanning, so your team can easily work out where your build time is going.


So what are you waiting for? Get building with Pipelines and make your build the fastest it can be.

Links in Bitbucket Pipelines logs

By on May 23, 2017

Here’s a small but useful improvement we added last month to Bitbucket Pipelines. You no longer need to copy and paste URLs from logs into your browser as Bitbucket will automatically turn them into links. Convenient for jumping to your deployed application!

links in logs

Try Bitbucket Pipelines

Document changes with required issue keys in Bitbucket Cloud

By on May 16, 2017

“Why was this change made again?” Issue keys referenced in commit messages help answer this question by providing a link with more context around why a particular change was made. They’re useful for everyone from new team members getting their bearings with a repo, to quality engineers reviewing the latest release, or a budding startup getting back to their weekend project.

Issue key references are so important that some teams need every commit to include a reference. These teams rely on issue keys to maintain diligent documentation or to automatically generate release notes or changelogs to verify every change. Historically, they could do this with pre-commit Git hooks on each developer’s machine to validate messages, but this solution adds a layer of overhead that becomes difficult to manage. For these organizations, we’re introducing the ability to require issue keys for commits in Bitbucket Cloud.

Required issue keys in Bitbucket Cloud

Requiring issue keys ensures each change links to an issue in commit messages. Bitbucket automatically converts mentioned issue keys (e.g. ‘PROJ-1234’ or ‘#1234’) into links to your issue tracker so it’s easy to stay coordinated between a change and its backstory.

Issue keys aren’t just a reference. They can be used to automate workflow actions: you can add comments or transition an issue to a different state just by mentioning it, making it easier for your team to go back historically for validation of changes. If you combine this with the new JIRA issue details view, you can view and comment on JIRA issues without even leaving Bitbucket. As a result, including issue keys has become a best practice and requiring them in commit messages will make it easier to scale your workflow.

Get started with required issue keys

If you’re new to Bitbucket, sign up for a Bitbucket Cloud account. If you’re an existing Bitbucket user and are already using JIRA Software, make sure it’s connected to Bitbucket. This connection enables Bitbucket to automatically link to your JIRA Software issues. If you’re using the Bitbucket issue tracker, issues are already linked automatically.

Then, navigate to the “Links” section of your repository settings and enable “Require issue keys in commit messages.”

Once enabled, Bitbucket will only accept pushes to your repo if all pushed commit message contain issue keys.

Once all commit messages include keys (e.g. using interactive rebase to update the message), the push will succeed, and the issue keys are automatically linked across Bitbucket, like in this pull request.

Try Bitbucket, it’s free

Not using JIRA Software and Bitbucket together?

JIRA Software is the preferred issue tracker of over 350,000 Bitbucket teams. Teams who have JIRA Software and Bitbucket integrated release 14% more often and close 23% more issues (when compared to teams using just one of those products).
Learn more.

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.