Upgrade a self-hosted build cache and keep its data
Can you move a build cache to a newer release without losing what it holds? I tested it with the only two published releases: I stored entries on 0.1.0, started 0.2.1 on the same data volume, wrote more, and then went back to 0.1.0. This is what happened.
What was tested, and what was not
- Tested: Docker, one named volume at
/home/nonroot, release 0.1.0 and then 0.2.1 (and back), no password, stopped and started cleanly between versions. - Not tested: any other pair of releases (there is no 0.2.0 release; see the changelog), upgrading while the server is running, Kubernetes or Compose rollouts, the FIPS image, or a cache that was close to its size cap.
The upgrade
docker pull ghcr.io/fosterstack/cache:0.2.1
docker stop fscache && docker rm fscache
docker run -d --name fscache -p 127.0.0.1:8080:8080 \
-v fscache-data:/home/nonroot \
ghcr.io/fosterstack/cache:0.2.1Use the same volume and the same settings (environment variables for the password and size cap) as the old container. Pin the exact tag you want, as above, rather than latest.
What I saw
| Step | Result |
|---|---|
| 0.1.0: store three entries on a fresh volume | 201 each; its metrics show 3 entries, 29 bytes |
| Stop 0.1.0, start 0.2.1 on the same volume | starts normally; the status page shows "version": "v0.2.1", 3 entries, 29 bytes; all three values read back |
| 0.2.1: store two more | 201 each; 5 entries |
| Stop 0.2.1, start 0.1.0 on the same volume again | starts normally; all values read back, including the two written by 0.2.1 |
So in my test an upgrade lost nothing, and a rollback to the old release could still read what the new one had written.
Two differences between the releases
- 0.1.0 has no status page.
/statuszreturned 404 there. 0.2.1 has it. The metrics page is on both. - 0.1.0's entry count resets after a restart. After the rollback its metric
fscache_store_entriesread 0 although every value was readable. I checked whether that was caused by the upgrade: it is not. A volume only 0.1.0 ever wrote showed 3 entries before a plain restart and 0 after it, with the data still readable. 0.2.1, restarted the same way, reported 3 entries and 9 bytes correctly.
If you want a safety net
A build cache can always be rebuilt, so losing one costs time, not work. If refilling would hurt, take a copy first: back up and restore a build cache. To start clean instead: clear or reset a build cache.
Related: how releases are built and signed and verify a release yourself, so you can check the new version before you run it.