Eviction
Both your local store and the box keep themselves under a size limit, and optionally an age limit. When they are over, they remove the results used longest ago. You rarely need to think about it, but here is how it works and why it is safe.
The limits
| Size | Age | When it runs | |
|---|---|---|---|
| Your machine | SHIPPY_MAX_SIZE, or max_size under [cache] in your user file (not a project's shippy.toml: the store is one for all your projects). Default: half of the store's own size plus free disk space, at most 50 GB | max_age / SHIPPY_MAX_AGE. Default: none | shippy gc, and after a build, at most every 10 minutes |
| The box | --max-store-size. Default: three quarters of the store's own size plus free space | --max-age. Default: none | Every 30 seconds |
The defaults follow the disk. A Hand with a 100 GB disk and 30 GB free gets 15 GB, which holds a dev build of tempo with its executable (8.7 GB) and a dozen edits. A laptop with 400 GB free gets 50 GB.
What goes first
- A whole result goes at once, the one used longest ago first.
- A blob goes only when no result refers to it any more.
- Results go until the store is at 90% of the limit, so the next few builds don't each start another round.
- With an age limit, anything unused for that long goes whatever the size.
On the box: nobody pays for someone else's uploads
The box is shared by principals who are not all trusted, so it counts public things apart from what each principal holds for itself:
- Public: results everyone is served, the blobs they name, and trusted packs. They are weighed against the limit on their own, so nothing an untrusted principal sends decides which public result goes.
- Held: claims, untrusted packs, and blobs no public result names. These go first when the store is over its limit.
- A share per principal: an untrusted principal may hold
--principal-sharepercent of the limit (10 by default). An upload that would go past it is refused with507, and the next round makes room out of that principal's own oldest bytes. The client then sends again.
Grace periods
Nothing stored or used within the grace period is removed: 15 minutes on the client, --evict-grace on the box (15 minutes by default). A running build may have fetched results it hasn't restored yet.
Results waiting in the upload queue are kept for a day.
Why it can't break a build
Every reader already treats a result with a missing blob as no result. So the worst a round can cause is one extra compilation:
- The wrapper checks that every output is in the store before it restores, and compiles if one is missing or if restoring fails halfway.
- On the box, only results whose blobs are all present are ever answered.
- A round removes a result before its blobs, and looks at each file again just before removing it.