Cache

Cache in Buddy

The working speed of pipelines is essential to any CI/CD tool. Buddy improves pipeline performance by caching resources that would otherwise have to be generated or downloaded on every execution. Here's what is cached:

1. Repository files, dependencies and artifacts (cached within the Pipeline Filesystem)
2. Docker images in which build actions are run (no need to build the environment from scratch every time)
3. Docker images used in the Run Docker Container action
4. Docker layers built with the Docker Build action

Additionally, you can enable cache for services and databases attached to build actions or an extra cache individually per build action.

Pipeline filesystem cache

Each pipeline has its own filesystem. During the first execution, the repository is cloned to the filesystem. The subsequent executions only fetch new changes from the repository (git fetch).

The pipeline filesystem is available for every action executed in the pipeline:

1. Build actions are run in a Docker container to which the filesystem is mounted. By default, all build commands are executed in the context of the filesystem.
2. Deployment actions are also run in the context of the filesystem, enabling you to deploy artifacts built in previous actions.

Cache in build actions

Repository, dependencies and artifacts cache

Builds, tests and other commands defined in the build action are executed in the context of a filesystem containing the repository. As we mentioned above, this is the primary cache of the pipeline.

If your builds fetch dependencies to a directory different from the default build context, you can cache them by entering their paths in the Cache tab:

Build environment cache (Docker image)

Build actions are run in Docker containers. The build environment is based on the Docker image pulled from a registry. On the first execution, Buddy will pull and cache the image in the selected version. If you set the tag to 'Latest', it will check for a new version by running docker pull on every subsequent execution. The procedure will only download Docker layers missing in the previous execution.

This way you don't have to pull the full image every time, and you're always sure that you're using the most recent version. The same rule applies to the Run Docker Image action.

Environment customization cache

You can also customize the Docker image in the build action by entering commands in the Environment tab. The commands will be run on the first pipeline execution to create a new image. It will be used until a new image is chosen the customization commands change.

Databases and services cache

All build actions support microservices (MySQL, MongoDB, Redis, etc.). The services act like individual containers with separate caching systems. To learn how to activate a cache for your service, click here.

Build Docker image action cache

The layers built in the Build Docker container action are cached. During the subsequent build, only those layers are built which weren’t built in the previous step. You can read how Docker cache works and how to create a Dockerfile in this document.

Run Docker container action cache

Images that you run in the Run Docker container action are cached and the cache relates to the whole workspace. You can find the way how it works above.

Clearing cache

Sometimes you may want to clear the cache, for example, if you need to regenerate the artifacts. In such a case, you can either clear the cache once or select an option which will do that automatically before every execution.

You can check the overall volume of consumed spaced

One-time cache clear

If you go to pipeline settings, you'll find the 'Clear pipeline cache' option in the right menu:

Automatic cache clear

You can select the "Clear cache before running" option in the project options if you want it to happen automatically:

You can select this option one-time when you run the pipeline manually or you may use commit commands.