New IP addresses for Bitbucket Cloud

By on July 2, 2018

What are we doing?

We’ll start a gradual rollout of changing our A records in DNS starting at 22:00 UTC on Sunday, July 29 2018 to point to new IP addresses. The rollout is expected to be completed for all our customers two weeks later, i.e by the 15th of August.

There will not be any downtime for this migration, and most people will not have to do anything differently because of this migration.

Why are we doing this?

Bitbucket has seen amazing growth over recent years, with millions of users working in Bitbucket to build better software. As part of that, we are planning a Cloud migration which will allow us to:

How will this affect you?

Most users will not have to do anything special for this migration. Your DNS servers should pick up the new IPs within a few minutes of the migration, and your systems should start using the new IPs right away. We’ll keep the old IPs running for a few weeks afterwards just in case, though.

Firewall considerations

If you control inbound or outbound access with a firewall, then you may need to update your configuration. Please whitelist these new IPs now; you should be able to remove the old IPs after the migration is complete.

New destination IP addresses for bitbucket.org, bitbucket.com, api.bitbucket.org, bitbucket.io, bytebucket.org, altssh.bitbucket.org will be:

Note: this IPv6 range includes subnets that are not necessary owned by Atlassian, but is the longest subnet that matches *all* Bitbucket IPv6 Atlassian IPs. We will post a list of the exact IPv6 addresses at https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html soon.

Webhooks IPs will remain unchanged as per https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html

SSH considerations

Our 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 resources

Bitbucket Cloud Dev Week wrap up

By on June 28, 2018

As part of the update to Bitbucket Cloud’s V2 APIs we announced a couple of weeks ago, we invited five companies from our developer ecosystem to build apps during Dev Week, a week long event at our offices in San Francisco. The premise of the week was simple – with a focus on providing a more robust and consistent usage experience when building integrations with Bitbucket Cloud, what better way to put the updated APIs to the test than putting them in the hands of app developers themselves? A number of Bitbucket Cloud developers teamed up with these partners, helping them build their integrations on the Connect platform and helping identify other ways we can improve the APIs and the overall developer experience.

We received great feedback throughout Dev Week, with everyone impressed with the new APIs and with Connect in particular, which allowed them to build their apps at speed and with ease.

“Our product integrates with a lot of tools in a developer’s toolchain, and integrating with Bitbucket Cloud was by far the easiest so far.”Sourcegraph

Each of the five partners plan to release their apps shortly, and we’ll be highlighting each one with blogs over the coming months. Here’s a brief look at the apps coming to Bitbucket Cloud in the not-too-distant future.

Fossa

Fossa provides tools that continuously scan and comply with open source licenses without slowing down development. For Dev Week, they built a “Dependency Insights” dashboard for Bitbucket Cloud, allowing users to view an index of all the third party code their team depends on and receive alerts about any issues at-a-glance.

JFrog

JFrog builds tools that handle artifact management and distribution, including Artifactory and Bintray. They focused on building a release management dashboard in Bitbucket Cloud that shows artifacts created during a release cycle that works with both Bitbucket Pipelines and Bamboo. They also built a second integration with Bitbucket Pipelines to push packages to Artifactory using the JFrog CLI.

pullRequest

pullRequest is an integrated marketplace for code review, allowing teams to get their code reviewed through pullRequest’s network of third party developers. The team built a real time review app that syncs code review work being performed by third party reviewers in pullRequest with the Bitbucket Cloud pull request.

SonarSource

SonarSource provides world-class solutions for continuous code quality. The application they built during Dev Week targets teams who analyze their source code on SonarCloud and who want to display code quality results inside Bitbucket Cloud, from the repository overview page, inside pull requests, or triggered via Bitbucket Pipelines.

Sourcegraph

Sourcegraph is a tool that helps code search and intelligence. The team built additional search and forward navigation into Bitbucket Cloud, including hover tool tips that allows users to jump to the definition or all the references to a function or class in Sourcegraph.

A big thanks to all the partners who attended the week and helped put our updated APIs and docs to the test. And if you haven’t tried them out yourself, give them a go and let us know what you think!

 

 

 

Instant notifications for your Bitbucket Pipelines builds

By on June 19, 2018

Earlier this year in April, we announced Bitbucket Cloud’s new and improved chatbot and the range of notifications that can be sent to your Slack channel. Amongst the improvements are notifications for Bitbucket Pipelines. You can now choose the notifications you’d like to receive on a per-channel and per-branch basis to keep the right people on the team notified when a pipeline succeeds, fails or is fixed.

Per-channel and branch notifications

Receiving notifications for every build in the team’s main channel can become quite noisy. This is why the default behavior for a new chat subscription is to only send pipeline failed and pipeline fixed notifications for builds on the repository’s main branch.

slack-config-pipelines

You can also customize your notifications experience to suit your team’s needs. For example, builds on your personal development branch can be sent to your private channel while builds on master or the main branch are sent to the broader team. This way, the team is notified only when it is relevant.

Rerun your build from your channel

Sometimes, builds can fail because of external factors – for example, an external deployment tool may have insufficient resources – and simply rerunning the pipeline will allow it to execute successfully. Our pipeline failed notifications are optimized for this scenario, letting you rerun your build from within your Slack channel.

pipelines-fail-notification

Updates when your pipeline is fixed

Notifications for successful builds can generate a lot of noise in a channel but there are times when it’s important to know when the pipeline has succeeded. We’ve introduced pipeline fixed notifications for this reason, giving your team confidence that bugs have been resolved and the pipeline has returned to a successful state after a previous failure.

pipelines-fix-notification

Pipeline information without leaving Slack

Alongside pipeline status notifications, Bitbucket can also provide you with contextual information about your pipeline. If you reference a link to a pipeline in your channel, Bitbucket will show you all of the relevant information about the pipeline – its status, duration, branch and commit hash. This helps provide the team with context about the build without needing to leave Slack.

pipelines-link-unfurl

Upgrade your chat notifications today

To connect your Bitbucket repository to Slack:

If you’re using the legacy Slack integration, make sure you uninstall it to avoid receiving multiple notifications for your builds.

This integration will be coming soon to Stride, so stay tuned for updates. We hope you enjoy the upgraded notifications experience!

New Bitbucket Cloud V2 APIs

By on June 15, 2018

Today Bitbucket Cloud is proud to announce an update to its V2 API, designed to offer developers a more robust and consistent usage experience when building Bitbucket Cloud integrations. And while we’ve improved the API and its documentation to make for a smoother integration experience, we’re most excited for you to try the changes we’ve made to Bitbucket Connect and the API Proxy. It’s now easier than ever to build efficient and performant apps for Bitbucket Cloud.

Build with greater coverage, consistency, and control

We heard from many of you that consistency was lacking with version 1.0 of Bitbucket Cloud’s API, and we’ve set about focusing on a more consistent experience with this update. And with more exciting changes to come, you can expect more thoughtful design and uniformity moving forward.

With that in mind, here are the biggest changes to Bitbucket Cloud’s V2 API.

Filtering results with BBQL and partial responses

Bitbucket Query Language (BBQL) is a generic querying language you can use to filter results from Bitbucket. With BBQL you can configure your Bitbucket integrations to only request and handle the data that matters to them. Different but related is the ability to query for partial responses, since this lets you be explicit about what fields you do or don’t want included in the response. These methods for filtering the response data aren’t just useful for trimming down the data returned to your application, they actually improve the time taken to process the request in Bitbucket thanks to lazy evaluation of the data being returned.

See it in action

In the following example we’re querying for issues with a title like “timeouts” and where the issue priority is at least “major”, and we’re asking for exactly the title, state and assignee username to be returned in the response. The q query parameter indicates some BBQL that we want to include, and the fields query parameter indicates that we want to use partial responses to choose what fields are returned.

In the next example, we use BBQL to query for pull requests that were created after the 1st of February 2018, and we use the additive partial responses operator to request that the reviewers are also returned in the response (by default they are omitted).

If you are familiar with GraphQL, you’ll find that the combination of BBQL and partial responses brings a lot of that power and flexibility to plain REST endpoints.

Better dev docs, for the win

Good APIs are nothing without good documentation, so we spent time addressing the gaps and inconsistencies we found in our developer documentation with this update. Our new API documentation is built on top of the Open API Specification 2.0 (formerly Swagger), and as an Open API member organization, we built and released the RADAR doc generator tool for rendering documentation written according to this specification. Our updated documentation is designed to offer a more thorough and understandable overview of what endpoints are available and how they work.

Like everything we build at Atlassian, we depend on feedback from our integrations partners. So peruse through our doc and give us some feedback in the Atlassian Developer Community. Tell us, what’s working? What’s missing? Where can we do better?

New APIs recently released

We recently rolled out some new additions to the V2 API to help you write amazing integrations. Check out the fancy new documentation for:

Bitbucket Connect and the API proxy, a game-changer

Last but certainly not least, we have Bitbucket Connect. For those unaware, a great way to develop integrations for Bitbucket Cloud is to use the Atlassian Connect framework. Integrations built using Atlassian Connect can do things like query the Bitbucket Cloud APIs on behalf of users, and also add content to the UI to customize the look and feel of apps built for Bitbucket.

Another great benefit of apps built with Connect is the ability for apps to add their own endpoints to the Bitbucket Cloud API. Requests to such resources are proxied via Bitbucket Cloud and then sent on to the application for handling. Doing this comes with a host of benefits, including:

This is our most exciting change with our new API improvements. Why? Because the proxy module aims to provide a much tighter and simpler integration experience for applications. We’re excited to see what you build with it, and encourage you to leave some feedback in the Atlassian Developer Community to tell us how you’re using it, and how it can be improved in future iterations.

V1 is now deprecated – As of today the V1 API is deprecated and we encourage all third-party developers to migrate over to our shiny new V2 APIs.

 

Try Bitbucket free

 

Bitbucket Cloud enhances enterprise cloud security with SOC 2 Type II report

By on June 13, 2018

The most important things to look at when deciding where to host your code with a cloud provider are cloud security, confidentiality, and availability. Without those important components, features, price, and integrations simply don’t matter if you don’t know your code is secure.

How do you know the company hosting your code is properly guarding it, and giving the right people access to your repos only with your permission? How can you be sure they don’t accidentally delete something? Bitbucket Cloud is the first of the leading Git repository solutions that can give you this assurance by successfully completing a SOC 2 Type II audit. What does this mean for you?

Bitbucket cloud security soc 2 type II

Confidence in code security, confidentiality, and availability

Whether you’re already a medium to large sized company or quickly becoming one, security and availability are your top priorities when managing your organization’s code within a DVCS. If (and when) your compliance team steps in and asks for assurance that your Git provider’s security and availability are in line in the cloud, what do you do? If your customers are asking you for SOC 2 Type II, what do you do?

With Bitbucket, you hand over our SOC 2 Type II certification and go on with your day. With other Git providers, you could embark on a 2 year journey of exchanging security questionnaires, negotiating with your security and compliance teams, and generally getting frustrated instead of just moving on with your real business. 

By having Ernst & Young complete this audit, we’ve assured that we have the checks in place so we won’t expose your code, we won’t lose your code, and our cloud has the correct processes in place to stay up. Bitbucket is now the most trusted place to store your code and grow with you.

SOC 2 Type II unblocks the cloud for on-premise teams

On-premise teams have wanted to use the cloud for its flexibility to scale, decreased hardware costs, automatic software updates and the ability to access information anytime but have felt blocked by concerns over cloud security. Having your full software development workflow in the cloud from apps to your CD pipeline can and will accelerate business velocity.

Now, with SOC 2 Type II, teams are able to make that move from server to cloud with assurance that their code is safe and reap the benefits of the cloud.

Enterprise-grade cloud security controls

In addition to SOC 2 Type II compliance, Bitbucket Cloud offers enterprise-grade security controls to further ensure your code is secure.

Required 2 step verification, IP whitelisting and merge checks are available under Bitbucket’s Premium Plan for $5/user/month.

Step up your security

If you’re ready to enhance your security measures, sign up for a Bitbucket Cloud account.

Try Bitbucket free

Fast-forward merges in Bitbucket Cloud – and by default, if you like

By on June 12, 2018

Imagine this scenario: your code’s ready to go, your teammates have approved your pull request, and the builds are green. Now you just need to merge your feature branch into master, but you have a choice to make: which merge strategy should I use?

Natively, Git offers several merge strategies. In Pull Request Merge Strategies: The Great Debate, fellow Atlassian Nicola Paoluicci presents the merge strategies that are most popular amongst teams, along with the pros and cons of each option.

As Nicola’s post mentioned, teams at Atlassian lean towards using explicit merge commits:

what is a merge

Some teams prefer to forego merge commits to maintain a linear commit history. Bitbucket already supports squash on merge, which results in a single commit on the destination branch containing your merged changes. The result? A tidy list of commits – one for each merge:

squash on merge

However, squashed merges can be undesirable in some cases: you may want to maintain a linear commit history without squashing to a single commit. For example, if your feature includes an API change and a front-end change, you might prefer to keep those changes as separate commits – but you still want a linear history without merge commits.

Fast forward merge strategy

That’s why we’ve added fast forward as an available merge strategy. fast forward merge will apply your source branch commits to the destination branch by moving the HEAD of the destination branch to the HEAD of your source branch (if there are no other commits on the destination). All without a merge commit. This maintains a linear history while keeping all of the commits from your source branch intact:

fast forward merge

To use the new fast forward option the next time you merge, select it as your desired Merge strategy in the merge dialog:

merge pull request

Default merge strategy repository setting

As a matter of team policy, some teams would prefer to always use the same strategy. To make this easier, we’ve introduced a default merge strategy repository setting.

This setting determines which merge strategy should pre-populate by default when your team members merge a pull request in Bitbucket. From your repository Settings, you can find this option on the Merge strategies page under Workflow.

merge strategies

We hope you enjoy! If you have any feedback to share regarding this feature, tweet us @Bitbucket. Happy merging!

Try Bitbucket Cloud

 

10 reasons why teams are switching from GitHub to Bitbucket after Microsoft acquisition

By on June 4, 2018

After the announcement of Microsoft’s acquisition of GitHub, Bitbucket started to see a spike in the number of GitHub users migrating their repositories to Bitbucket. Why? Many users understand they can get everything they had on GitHub in Bitbucket plus more, and at a lower cost. Tens of thousands of customers – including 60 of Fortune 100 – turn to Bitbucket as their code collaboration solution.

Start migrating from GitHub to Bitbucket

 

10 reasons why teams are moving from GitHub to Bitbucket Cloud

1. Price

Teams can save 4x the cost moving from GitHub to Bitbucket. For example, if you are a team of 10 on GitHub, you have to pay $205 a month, while on Bitbucket you’re only paying $50. Bitbucket also offers free public and private repositories for teams with less than 5 users. GitHub doesn’t offer a free plan for users who want private repositories. On GitHub, even an individual developer has to pay $7 a month.

 

2. Superior integration with Jira

It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams.

GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:


3. Built-in Continuous Integration and Delivery

On Bitbucket, you get a built in CI/CD solution that is unified with your source code. There are no CI servers to set up, user management to configure or repositories to synchronize. Just enable it within the UI and you’re done. What about with GitHub? Nope. GitHub doesn’t have a CI/CD solution. You have to go through the headache of finding, installing, configuring a new tool, setting up all your users over again, and you don’t benefit from the end-to-end visibility because all your CI information lives in a separate tool.

 

4. Bitbucket comes with Trello

This means the moment you set up a Bitbucket account, you get a Trello board – the fastest, easiest way to organize your projects, connect your work to code, and ship software, all for free.

 

5. SOC 2 Type II Compliance

With SOC 2 Type II compliance for both Jira Software and Bitbucket, the availability and security of your code is guaranteed. All the benefits of working in the cloud is now matched with an industry-first level of security, confidentiality, and availability for both your work and your code. Nah, GitHub is not SOC 2 Type II compliant.

 

6. Seamless integrations within the UI

Bitbucket Connect allows any developer to build deep integrations within the product UI in Bitbucket Cloud. You can stay within one tool to build and ship your software meaning no more context-switching between tools and tasks to get stuff done.

7. Code aware search

Semantic search that does the grunt work for you. Code aware search analyzes your code syntax, ensuring definitions matching your search term are prioritized over usages and variable names. With GitHub, you don’t get smart sorting and could spend hours finding what you need.

8. Mercurial Support

Bitbucket Cloud has Mercurial support. Mercurial is a free, distributed source control management system like Git. Have the freedom of choice and use the distributed version control system that works for you. GitHub? Nope.

9. Great for Open source projects too

Think GitHub is the answer for open source projects? Did you know Bitbucket also offers free public repos as well and hosts several large open source projects?

10. Using Slack?

With the Bitbucket bot for Slack, teams can take action from their channel – merge, comment, and even nudge reviewers on pull requests. With the Bitbucket Stride integration, you can “poke” people reviewing your PR as well. Nah, GitHub doesn’t have that either.

Are you self-hosting? Here are six reasons teams choose Bitbucket Server:

1. Price

Our enterprise offering, Bitbucket Data Center, is 4x less expensive than GitHub Enterprise. For an engineering organization of 100 on GitHub Enterprise, you’ll pay $25,000 for a year. Bitbucket Data Center costs a fraction at $6000.

2. Native integration with Jira

It’s been known for a long time that one of the best benefits of using Bitbucket is it’s best-in-class integration with Jira – the worlds number 1 agile software development tool for teams. GitHub has an integration too, but check out all the things you can do with Bitbucket and Jira that you can’t do with GitHub:

 

3. Bitbucket has better mirroring

GitHub Enterprise finally added mirroring Git repositories across different geographic locations, but can it keep up with Bitbucket Data Center? Select which projects are mirrored in a geographic location and Bitbucket will automatically sync and inherit user permissions. GitHub mirrors every repository, creating a bottleneck when pushing changes out.

4. Customizable pull request workflows

Bitbucket allows you to choose between five different merge strategies, create (and require) custom merge conditions, and configure default reviewers. GitHub expects you to use GitHub flow and be happy about it.

5. Superior extensibility

The Atlassian Marketplace houses over 200 Bitbucket Server compatible apps and more than 140 for Bitbucket Data Center. GitHub has 50. Not only do we offer more apps, but you also get access to the self-hosted Bitbucket’s source code. You’ll have to keep your GitHub representative on speed-dial for similar access.

6. Turnkey active-active clustering

We believe Git should scale with you. Easily add nodes to your Bitbucket Data Center cluster as your team grows. GitHub would rather you call them first before you can have an active-active cluster.

Start migrating from GitHub to Bitbucket

Move your team to Bitbucket Server

Support for Xcode in Bitbucket

By on

Developer efficiency is always top mind for the Bitbucket team and we’re constantly looking at ways to get you up and coding as quickly as possible. For example, knowing so many of you use Sourcetree as your Git client of choice meant it was a no-brainer for us to add a ‘Clone in Sourcetree’ button as you browse through your repositories inside the product.

We’ve been looking at ways to expand this type of functionality and today we’re excited to announce support for Xcode. It’s simpler than ever to open the code found in Bitbucket Cloud or Bitbucket Server in Xcode – as long as your repository contains a .xcodeproj or .xcworkspace file a new ‘Clone in Xcode’ button will now appear.

And it’s easy to get the button working with the newly announced Xcode 10 – simply add your Bitbucket Cloud or Bitbucket Server credentials in Xcode and away you go:

Once set up, clicking on the “Clone in Xcode” button will launch Xcode and prompt you for a location on your local machine to clone the repository to.

Give the new integration a try and let us know what you think!

 

 

Try Bitbucket free

 

Using Bitbucket Server? This integration is available from 5.11 onwards. For those using versions 4.0 – 5.10, you can install it via Atlassian Marketplace.

 

Deprecating TLSv1 and TLSv1.1

By on May 31, 2018

As part of our never-ending quest to secure your repositories, Bitbucket Cloud will be disabling support for TLSv1 and TLSv1.1 effective 1 December 2018.

This will affect all HTTPS traffic to Bitbucket, including:

SSH traffic to bitbucket.org or altssh.bitbucket.org will not be affected by this change.

About 85% of HTTPS requests to Bitbucket use the newest version of TLS (v1.2). This includes all recent versions of our supported browsers, and most recent versions of Git and Mercurial clients. However, that other 15% includes a number of remote CI/CD systems (such as Bamboo or Jenkins), issue trackers (such as Jira Server instances), wikis (such as Confluence Server instances), and older versions of Git/Hg clients; all of those use older versions of Java, OpenSSL, or Python’s ssl module when negotiating the secured connection to Bitbucket, and all of those will be unable to connect to Bitbucket at all once we disable old versions of TLS.

Payment processing pages have already moved from TLSv1, to comply with PCI requirements.

How can I tell if I will be affected by this change?

We’ll 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 or Mercurial 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?

Upgrade anything that is affected, before 1 December 2018. The exact details of your upgrade will depend on what you use, and how it’s installed; we don’t have enough room here to list all the different combinations, unfortunately, but we hope that the “will I be affected” section can point you in the right direction. (We’ll remind everyone as December approaches, but if your stuff is affected then you need to start planning this out now.)

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 versions of TLS in six months’ time.

As always, please contact our support team if you need additional information.

Why Bitbucket Pipelines is the best CI/CD tool for your Docker-based software

By on May 29, 2018

In the Bitbucket team, we believe containerization is the future of continuous integration and deployment. Running your software in containers brings consistency and predictability all the way from your development environment, through your CI/CD pipeline out to production.

To help smooth the path for container-based development, I wanted to reflect back on a set of improvements we’ve made to Docker support in Pipelines over the past few months, which bring speed and new capabilities to your build process. With these improvements, Bitbucket Pipelines is now the leading choice for building and shipping Docker-enabled applications in the cloud.

Pipelines is Docker all the way down

Docker applications will feel at home on Bitbucket Pipelines because everything in Pipelines is built on Docker:

Here’s a diagram showing how this all fits together:

pipelines-docker-containers

But this is just the beginning with Pipelines. From this solid foundation, we’ve been able to layer on some great features that will make your Docker builds even faster and more powerful.

Lightning fast builds thanks to comprehensive Docker caching

“My build is too fast”, said no developer, ever. We’ve built several levels of caching into Pipelines for Docker users, so your Docker builds can run as fast in the cloud as they do locally:

Among customers who have enabled Docker layer caching, we’ve seen 80% of repositories shave off more than 30% of their uncached build time – and almost half (49%) have cut more than 50% off their uncached build time. These dramatic reductions will save real time in your team’s daily feedback loop.

Docker builds up to 7GB with configurable memory limits

With two improvements that enable bigger and more complex builds, you can now use up to 7GB for building and running Docker containers in Pipelines:

Here’s an example of configuring 7GB for Docker operations in bitbucket-pipelines.yml:


pipelines:
  default:
    - step:
        size: 2x  # double memory (8GB) for this step
        script:
          - ... # do some memory-intensive docker stuff
        services:
          - docker
        caches:
          - docker

definitions:
  services:
    docker:
      memory: 7168

This additional memory might make you wonder why you wouldn’t just spin up your entire application in Pipelines for some delicious integration testing. Which leads us on to…

Spin up your entire application with docker-compose

If you’re using Docker heavily, you probably have a bunch of docker-compose YAML files to kick off your application in a variety of configurations. With the Docker-in-Docker daemon in Pipelines, you can now use docker-compose to spin up your entire application for testing.

Below is an example of using docker-compose with a 7GB memory allocation to spin up a set of services and test them out.

Note that this example has a few extra commands to install the mysql client and docker-compose binaries that aren’t necessary in a real build scenario, where you would bake your dependencies into a custom Docker image for your build environment.


pipelines:
  default:
    - step:
        size: 2x   # double memory (8GB) for this step
        services:
          - docker
        caches:
          - docker
        script:
          - apt-get update -y && apt-get install -y mysql-client
          - curl -L https://github.com/docker/compose/releases/download/1.19.0/docker-compose-Linux-x86_64 -o /usr/local/bin/docker-compose
          - chmod +x /usr/local/bin/docker-compose
          - docker-compose up -d
          - docker-compose ps
          - ./wait-for-container.sh build_mysql_1
          - echo 'select 1' |
              mysql -h 127.0.0.1 -u root -psecret testdb
          - docker-compose logs mysql

definitions:
  services:
    docker:
      memory: 7168

This example uses this docker-compose.yml, and wait-for-container.sh – a small shell script to poll the Docker health check and wait for a container to start.

If you want a better look at how this docker-compose example fits together, check out the docker branch in my demo repository.

Try Bitbucket for your next Docker-powered project

If your team is big into Docker, you now have a list of great reasons to try out Bitbucket for your next project.

Try Bitbucket today, and enjoy the benefits of a CI/CD solution purpose-built for Docker.

Try Bitbucket free