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 -dThe -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 againTested 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 404Kubernetes
+Delete the volume claim. The cleanest way is to scale to zero, delete the claim, and scale back up:
+kubectl scale deploy/fscache --replicas=0
+kubectl delete pvc fscache-data
+kubectl scale deploy/fscache --replicas=1Keep 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.
Full detail: Docker deploy guide. Related: Gradle build cache with Docker Compose.
+ +