Deployment Cache

The Deployment Cache (DC) is a good way to speed up the build process of deployments. This feature is enabled by default on all repositories.

Squash generates a cache snapshot for the following types of apps, across all branches in a repository:

• A Squash YAML file, in case you are not using Docker
• Each unique Dockerfile or docker-compose file

This is done by keeping a md5sum reference of each file type listed above. When the content on one of these file changes Squash will build it from scratch and save a new cache snapshot, for any branch of code where DC is enabled.

A DC snapshot is only created when a deployment build process is successfully completed and when Squash encounters a success response.

Docker image & how the Squash cache works under the hood

Even for repositories not using Docker Squash still creates a Docker container behind the scenes. The Deployment Cache essentially works by generating a new Docker Image and saving it as a Deployment Cache volume.

Squash stores Docker images in a special location under the /home folder, your application code however, is always deployed under /home/test-instance/code. When you run a Squash deployment with a DC cache retrieved, Squash starts the host VM by replacing the /home folder with a previously cached version, this brings the appropriate Docker image. Your latest branch code will still be retrieved under the /home/test-instance/code folder. The cache will only be used if:

• The md5sum of the Dockerfile/docker-compose.yml file matches an existing DC volume
• For repositories not using Docker, the md5sum of the .squash.yml file needs to match an existing DC volume

Your application build process is always executed

Squash will always build your app normally using the latest code (except when persistent storage is enabled and successfully retrieved) even when a cached image is being used – this is to ensure that you always get the most up-to-date version of your app for a given branch. The cached image serves as existing layers that will be used by the Docker build process in order to speed things up.

Please note that every application is different and depending on your setup the actual speed gain of the Deployment Cache might not be noticeable.

How to enable the cache for docker-compose deployments

If you are using docker-compose please note that it’s required to add the cache_from field, inside the “build” field. Example:

version: '3.2'
services:    
  web_app:
    image: myapp/frontend:v1
    build: 
      context: ./src
      cache_from:
        - myapp/frontend:v1
    ports:
      - 3000:3000

This will ensure the cache gets properly consumed by docker-compose to take advantage of its layers.

How to disable the cache on a deployment level

Open a deployment settings page, then click on settings:

Then check the “Turn off Deployment Cache” checkbox:

This will disable the cache for future runs of this deployment.

Cache expiration

The deployment cache records automatically expire after 30 days of inactivity. The DC record will automatically renew for 30 days every time it gets used, it will only be deleted if it doesn’t get attached to any deployments within a 30 day period.

Web Interface

You can browse through a list of all available cached entries for all repositories in your account. From this page you can also manually delete cache entries which will force new deployments to be built from scratch, essentially generating new and fresh cache volumes.

NOTE: it may take from several minutes (deployment storage below 30GB) to over 30 min (deployments with 100GB+ of storage) for new cache entries to display in this page.

 

Invalidating the cache

There are several methods to invalidate DC records:

• By manually deleting records from the web interface mentioned above.
• Using the Squash API (see below).
• For projects without Docker: by modifying the contents of the Squash YAML file. This will essentially cause the md5sum of the file to change and Squash will automatically generate a new cache entry.
• For projects with Docker:
  • Dockerfile: Same as above, you need to change the content of the file to force Squash to create a new cache entry. In some cases it might make sense to add a unique version ID or hash as a comment in the file that you can use to trigger these updates.
  • docker-compose.yml file: Same as the the Dockerfile. Please note that Squash relies on the docker-compose file itself to generate cache entries. If a compose file uses multiple Dockerfiles, changing such files will not trigger a cache update.

Squash provides information on several areas on when a DIC snapshot is being used or not.

Historical Deployments page

The historical page also display this information: