Please cache

In various places in these docs you might find reference to caches. Please can make use of several caches to speed up its performance which are described here.

In all cases artifacts are only stored in the cache after a successful build or test run.
Please takes a --nocache flag which disables all caches for an individual run.

The directory cache

This is the simplest kind of cache; it's on by default and simply is a directory tree (by default ~/.cache/please or ~/Library/Caches/please) containing various versions of built artifacts. The main advantage of this is that it allows extremely fast rebuilds when swapping between different versions of code (notably git branches).

Note that the dir cache is not threadsafe or locked in any way beyond plz's normal repo lock, so sharing the same directory between multiple projects is probably a Bad Idea.

The HTTP cache

This is a more advanced cache which, as one would expect, can run on a centralised machine to share artifacts between multiple clients. It has a simple API based on PUT and GET to store and retrieve opaque blobs.

It is simply configured by setting the httpurl property in the cache section of the config. There are a couple more settings to configure it for readonly mode and to set timeouts etc.

Since the API is simple there are many existing servers that can be configured for a backend; one option is nginx using its webDAV module.
Alternatively some CI services (for example Cirrus) may offer a compatible cache out of the box.

Thanks to Diana Costea who implemented the original version of this as part of her internship with us, and prodded us into getting on and actually deploying it for our CI servers.

The RPC cache

This cache uses gRPC for communication. It is conceptually similar to the HTTP cache but uses a different protocol that is bespoke to Please.

It is nearing the end of its lifespan, the client remains in Please at present but we are no longer releasing new versions of the server (the last please-servers release is v13.8.2).
Any users should migrate to either the HTTP or remote execution caches.

The Remote Execution cache

This feature is still experimental; some aspects may not work fully or at all as yet. Proceed with caution!

This cache is based on Google's remote execution API. It functions similarly to the HTTP cache but will become more useful as we introduce further remote execution capabilities into Please.

It is configured by setting the url property in the remote section of the config. There are some more settings, of which instance is the most relevant here - that must be set in agreement with the server.