Part
Cache
You might say: dependency cache, reusable build cache
An optional store for dependencies or intermediate files that a run can regenerate. It speeds later runs without becoming their source of truth.
- What it does
- Cuts repeated downloads and setup time while leaving a clean run able to recover from a miss.
- Ask
- Can this run recreate the files when the cache is empty or poisoned?
- Typical
- Cache dependencies and intermediate outputs. Keep secrets and sensitive data out.
- Trouble
- A stale or poisoned cache changes the result, a cache miss breaks the task, or cache growth evicts useful entries.
What to look for
- A cache hit or miss line in the run log
- A key based on a lockfile or runner image
- A cache retention and eviction setting
Connections
- See also: Disposable environment
Sources
- GitHub, Dependency caching, Artifacts versus dependency caching
Use caching when you want to reuse files that don't change often between workflow runs, such as dependencies downloaded by a package management system, intermediate build outputs, or other files that are expensive to regenerate.
- GitHub, Dependency caching, Artifacts versus dependency caching
a job should always be able to re-download or regenerate these files if a cache isn't available.
- GitHub, Dependency caching, Cache security
Any run that can read a cache restores its contents as-is, so you should treat restored files as untrusted input and never store secrets or other sensitive data in a cache.
Use it on your project
teardown-apply: hold "Cache" (cache) from the teardown at https://teardownatlas.com/software-factory/ against my project
Paste it into a coding agent that has the teardown skills.
An AI agent wrote this map with the teardown skill. It can contain errors: check the sources before you rely on a part. About and legal