You've always been able to execute CI/CD workflows via Bitbucket Pipelines using Atlassian's infrastructure. This is the easiest way to use Bitbucket Pipelines because you don't need to host or manage any servers. We host it and manage it for you.
But sometimes you need more control of your hardware, software, and the environment your builds are executed into. For example, you may need builds to access internal systems that are behind the firewall, or configure your hardware with more memory to run complex builds.
To address this, in June, we announced an open beta for Pipelines runners. Runners allow you to execute your pipelines builds on your own infrastructure, so you have more control over your server configurations and budgets.
Today, we are excited to announce that we are moving from beta to an official release of runners.
Benefits of using runners
With Bitbucket now supporting the use of self-hosted runners, you can now point your builds to run on a machine that you specify. This can be a server that you host yourself behind the firewall or on a private cloud that you manage.
Here are some of the benefits of using runners.
- Custom build configurations: Runners allow you to configure your hardware for different types of builds. For example, if you have resource-intensive builds, using hardware with more memory can improve build execution time.
- Access internal applications or databases: When running pipelines on Atlassian's infrastructure, we cannot access your internal systems. If you need to run integrations tests against your internal databases or applications, you can do so with runners. Since these runners are hosted/managed by you, you can provide any access needed to internal services.
- Hybrid workflows: You can optimize your resources by using self-hosted runners with custom configurations for builds that require it and use Atlassian's infrastructure for other jobs. When using your own runners, we don't charge you for build minutes consumed by your runner.
If you are currently using Bitbucket Server with self-hosted CI/CD tools such as Jenkins or Bamboo and considering moving to Bitbucket Cloud, the option to use runners means that you can use Bitbucket Pipelines and still use your own infrastructure to run your builds.
How it works
Here’s a quick demo of how to register and use a runner in your pipeline.
Key features:
Manage runners at the workspace level: If you are a workspace admin, you can set up and manage multiple runners for your whole account so they can be used in pipelines across any repo in the workspace. This makes it easier and saves time in creating and manage your runners when you have many repos in your workspace.
If a runner is being used for another build, your pipeline will be put in a queue till prior jobs are completed.
If you are not the workspace admin but administer specific repos, you can only register runners that can be used in those specific repos.
Multiple runners per machine: To optimize the use of your resources, you can host multiple runners per machine and be able to differentiate between them in your yaml code. This is useful when you have a powerful machine and want to configure multiple runners on it based on what you need for different types of jobs.
Increased memory limits: You can allocate up to 32GB memory to your runners to run steps that take too long or are not possible on our default runners.
Specify runners for each step: In the pipelines yaml, you can specify which runner or runner group should be used for each step. For example, you may not need a runner with high memory for all steps. This helps manage runner resources so each runner is used for jobs that require that configuration.
In this snippet, step 1 runs on a runner while step 2 runs on default Atlassian infrastructure. Note that in step 1, there is a label reference. You can use labels to group a set of runners e.g. if you have a bunch of runners with 32GB of memory, you can label those runners as such and reference that in your yaml. So step 1 will run on any of the runners that have the label you specify.
Another benefit of labels is that you don't have to remember the exact names of the different runners. You can use labels to choose the appropriate runner for your job.
pipelines:
custom:
customPipelineWithRunnerStep:
- step:
name: Step1
size: 8x # default 4gb, 8x for 32gb
runs-on:
- 'self.hosted'
- 'my.custom.label'
script:
- echo "This step will run on a self hosted runner with 32 GB of memory.";
- step:
name: Step2
script:
- echo "This step will run on Atlassian's infrastructure as usual.";Get started
To learn more about how to set up and use your own runners, here is the technical documentation.
If you have questions on runners, post a comment on the feature ticket and our product team will get back to you.
