CacheVolumeOptions

interface in bldr

Options for cacheVolume.

Properties

mode: CacheMode

property

How concurrent holders share it:

• "shared" (default) — many at once, each one's result merged in as it finishes. For a cache of independent, content-named entries, where two pods add different things and neither removes anything. Deletions do not survive.
• "exclusive" — one at a time, and that holder's result replaces the volume. For a cache with internal structure concurrent writers would tear (an incremental-compilation directory), and the only mode in which a cache can shrink.

See CacheMode.

perImage: boolean

property

Give each rootfs image its own copy of the volume.

Needed by any cache a tool invalidates by timestamp. Content bldr bakes into an image has an mtime of 0 — the capture normalises it so two identical images share a CID — while a cached build output carries the real time it was written. A tool comparing them concludes the baked file is older and reuses what it built last time, even though the image changed. Cargo did exactly that with a .proto baked into its toolchain, and kept generated code from the previous version of it.

Leave it off for a cache whose entries are named by their own content — a package download cache is the same downloads whatever compiler wants them.

scope: Scope

property

The scope that owns this volume — its name is namespaced under that scope's path, so bldr/daemon's target volume is bldr/daemon/target and cannot collide with another member's.

Omit for a workspace-global volume, shared by every member that names it. That is what a package-download cache wants: one copy of a registry for the whole workspace, not one per project.

See Scope.