How to clear or reset a self-hosted Gradle build cache

There is no purge button. You empty the cache by removing its data and restarting. This page shows how, for Docker, Docker Compose, Kubernetes and a plain binary, and what it looks like when it works.

Why there is no purge button

The server has no purge endpoint and no admin web page, on purpose. Nobody can reconfigure or empty it while it runs, including us. A reset is a deliberate step in whatever manages your deployment, so it leaves a record there. The old Build Cache Node had a purge button; this does not.

It is also safe to do. A build cache holds results your builds can always rebuild. The first builds after a reset are slower while it refills, and that is all.

Docker Compose

docker compose down -v && docker compose up -d

The -v removes the named data volume. The fresh start sets up its ownership correctly.

Plain Docker

docker rm -f fscache
docker volume rm fscache-data
# then run your original docker run command again

Tested on the 0.2.1 image. Before the reset, /statusz showed one stored entry. After removing the container and the volume and starting again:

$ curl -s localhost:8080/statusz | grep -E '"store_entries"|"store_bytes"'
  "store_bytes": 0,
  "store_entries": 0,
$ curl -s localhost:8080/testkey -o /dev/null -w 'GET testkey %{http_code}\n'
GET testkey 404

Kubernetes

Delete the volume claim, then create it again. The Deployment cannot start without its claim, so the new claim is a required step. Tested on a throwaway cluster:

kubectl -n fscache-ns scale deploy/fscache --replicas=0
kubectl -n fscache-ns delete pvc fscache-data
kubectl -n fscache-ns apply -f fscache-pvc.yaml   # your claim manifest, the same one you first applied
kubectl -n fscache-ns scale deploy/fscache --replicas=1

Without the third line, the pod stays Pending with the event persistentvolumeclaim "fscache-data" not found. With it, the pod starts on an empty volume: /statusz showed "store_entries": 0 and a key stored before the reset returned 404.

Keep it at one replica. See Gradle build cache on Kubernetes.

A plain binary

Stop the process, delete the data directory, and start it again.

Check it worked

The status page at /statusz shows the entry count and the stored size. Both should be zero straight after a reset. For a size cap that fills up on its own, see server sizing.

We ran the Docker, Docker Compose and plain-binary resets again on a GitHub-hosted Linux machine with FosterStack Cache 0.2.2. After each one the server held 0 entries and the key stored before returned 404. After the Docker and Docker Compose resets, a new write got 201. For the binary, a plain restart first kept the entry, so the empty result came from deleting the data directory. The Kubernetes steps were not run there. The run and its log are public.

Full detail: Docker deploy guide. Related: Gradle build cache with Docker Compose.