Service containers for Bitbucket Pipelines
Bitbucket Pipelines allows you to run multiple Docker containers from your build pipeline. You'll want to start additional containers if your pipeline requires additional services when testing and operating your application. These extra services may include datastores, code analytics tools and stub webservices.
You define such additional services (and other resources) in the
definitions section of the bitbucket-pipelines.yml file. These services can then be referenced in the configuration of each pipeline that needs them.
When a pipeline runs, services referenced in a step of your bitbucket-pipeline.yml will be scheduled to run with your pipeline step. These services share a network interface with your pipeline step, and bound ports can be accessed via localhost.
Pipelines enforces a maximum of 3 service containers per build step, which is based on the limited memory available for builds in our infrastructure.
This example shows both the definition of a service and its use in a pipeline step. A breakdown of how it works is presented below.
Defining a service
Services are defined in the
definitions section of the bitbucket-pipelines.yml file.
Use a service in a pipeline
Once a service has been defined in the 'definitions' section of the bitbucket-pipelines.yml file, you can reference that service in pipeline steps.
For example, the following causes the
redis service to run alongside the step:
Use a private image
You can define a service that has restricted access as follows:
For more complete example of using docker images from different registries and different formats, see Using Docker images as build environments
Caveats and limitations
The number of service containers you can run in a build is limited by the available memory for the build:
- Maximum of 3 services.
- Each service has 1GB memory reserved for it that is taken from the 4GB limit for a pipeline.
|Number of services||Memory available for your pipeline|
The following parts of the feature are still under development:
- Service log collection and UI for displaying logs
- REST API for accessing services and logs under pipeline results
- No mechanism to wait for service startup.
Was this helpful?
Thanks for your feedback!