CachingWhen running beats downloading
When running beats downloading
If a download would take longer than running the task, vx runs the task. 500 remote hits finish in 1.15 s instead of 3.12 s.
// the vx blog
Caching
Posts tagged caching.
CachingCachingEvery task has a key
Every task has a key
A task you never cache still has a key. Change its inputs and every cached task after it runs again, so you never get a build made for old inputs.
CachingCache transfers wait on the network
Cache transfers wait on the network
Cache transfers mostly wait on the network, not a core. vx runs up to 64 at once, so 1,000 uploads to a cache 30 ms away take 2.5 s.
CachingA cache hit is a file copy
A cache hit is a file copy
A local cache hit is a file copy the kernel does. 1,000 hits of 96 KiB restore in 411 ms, and vx never hard-links.
CachingBranch caches a server enforces
Branch caches a server enforces
A pull request reads what main built and can never write where main reads. The CI token decides writes, one header steers reads. How it works, and how a cache server builds its half.
CachingAn input changes mid-run: what four task tools do
An input changes mid-run: what four task tools do
A file changes while a task runs. Does the cache save the output anyway? We read the source of vx, Turborepo, Nx and Vite Task.
CachingWhen an input moves mid-run, vx keeps the result and skips the save
When an input moves mid-run, vx keeps the result and skips the save
Save a file while a build runs and vx keeps the result but caches nothing, so a later hit never brings back output built from the wrong source.
CachingA glob stops at the next project
A glob stops at the next project
A project's globs stop at the next project's folder. A change elsewhere reaches a task only through a declared dependency.
CachingA cache that stays the size you chose
A cache that stays the size you chose
vx cache clean keeps the cache at the size you pick, by age and by last use. It refuses a bound of zero.
PerformanceA cold run asks the cache nothing
A cold run asks the cache nothing
With an empty cache, vx skips the lookups that would all miss. On 1,000 projects the first task starts 136 ms after vx run.
CachingA key with nothing to run
A key with nothing to run
A task can have inputs and no command. Tests that depend on it run again when those files change, and nothing extra spawns.
CachingWhat goes into a key, and what comes back
What goes into a key, and what comes back
Files, env vars, tool versions and upstream tasks go into the key. Outputs and logs come back. A damaged download is a miss, never a wrong build.
CachingA remote server you can trust in production
A remote server you can trust in production
Connect @vzn/vx-reapi to BuildBuddy or your own server. Repeat runs skip the worker, every byte is checked, and a stuck server is a miss, not a hang.
CachingA task sees only the env it names
A task sees only the env it names
Your shell holds dozens of variables, some of them secrets. A task gets a short fixed list plus the names you write down, and secrets print as ***.
CachingThe cache on your terms
The cache on your terms
Turn the cache off, refresh it, or read one layer and write another. Every clone shares one store, and a pull request never writes what main reads.
DXOne command to know your workspace
One command to know your workspace
vx info answers the first questions of every bug report on one screen: versions, workers, memory, cache size, flaky tasks, sandbox.
DXSee the plan before you run it
See the plan before you run it
vx run --dry shows which tasks would come from the cache and which would run, with keys and expected times. Nothing runs.
InternalsYour cache key is already in git's index
Your cache key is already in git's index
vx reads file hashes from git's index instead of reading your files: 2.3 ms for 2,527 files. A commit never changes a key.
InternalsHash what the config turns into
Hash what the config turns into
vx hashes your config after it runs. Change a preset you import and every task that uses it gets a new key, with no list to maintain.
CachingAfter a cache hit, dist holds only what was cached
After a cache hit, dist holds only what was cached
vx clears a task’s declared outputs before it runs and after a hit, so a deleted file never lingers in dist and gets shipped.
CachingEvery cache key is known before anything runs
Every cache key is known before anything runs
A task's key includes its dependencies' input keys, never their outputs. So every key in the graph exists before the first task starts.
DXvx why names the change that made a task run again
vx why names the change that made a task run again
You changed one file and got twelve rebuilds. `vx why` names the part of the cache key that changed, and follows it to the root cause.
CachingA lockfile bump rebuilds only what it reaches
A lockfile bump rebuilds only what it reaches
Core keys no lockfile, and folding the whole file into every key would make one bump rebuild everything. @vzn/vx-lockfile keys each task on its own project's dependencies, so an astro bump here rebuilds 8 of 151 tasks.
DXFlaky is a claim only declared inputs can back
Flaky is a claim only declared inputs can back
vx calls a task flaky only when the same inputs both passed and failed. Your local run history is enough, no service needed.