The core feature of Buddy is building and testing the application before it can be delivered to the server. Usually, you need a database or some other service if you want to test your app properly. On top of predefined services, such as MySQL, PSQL or MongoDB, you can create your own service from scratch. This feature allows you to run tests for both frontend and backend of your application, or to create a database service with custom configuration and use it in your builds.
Although Docker Compose is not yet supported by Buddy, custom services let you define basically any configuration that can be achieved through it. In fact, all build actions and services were designed to run in accordance with Docker Compose.
How to add a custom service
Custom services are added just like any other microservice. Just go to the Services tab in the build action and choose Custom service from the dropdown:
Upon adding the custom service, the following needs to be defined:
Hostname – the ID that will be used by other services to connect to this one
Docker Image — registry, image, and its version
- [Optional] Commands to run and filesystem to mount
Using your own image as a service
Buddy pulls images from the selected private or public Docker registry by default, along with dedicated support for Docker Hub, Amazon ECR and Google GCR registries. You can also use an image built by a preceding action in the pipeline. For instance, you can build images for both Frontend and Backend, and then use the Custom Build action to run and test them together. To do that, select Use Docker image built in previous action, and then choose the image below:
The entire pipeline will look like this, with two actions building both front- and backend of your app:
You can add up to 6 services to every single build action. The first one is the main image of the build action. The remaining 5 can be added in the Services tab.
Customizing services with ENV VARs and the filesystem
Each time a custom service is run, Buddy sends to it variables defined in the build action. This way you can customize the way it works. For instance, you can send
MYSQL_ROOT_USER variables to the official MySQL image in order to configure the image during its start:
Apart from that, you can mount the pipeline filesystem to the service if it requires access to files from version control, such as config files:
Caching data from services
Predefined services (MySQL, MongoDB, Postgres, etc.) can be cached. This means that the database is seeded only once, which speeds up the builds to a great deal. In order to cache data in a custom service, you have to use the pipeline filesystem (see above), or define the paths that will be cached for each service:
The volumes that have been mounted will remain persistent between executions, i.e. the cache will only be cleared manually from the pipeline settings, or when an execution is run with the Clear cache option enabled.