About workflow dependency caching
Workflow runs often reuse the same outputs or downloaded dependencies from one run to another. For example, package and dependency management tools such as Maven, Gradle, npm, and Yarn keep a local cache of downloaded dependencies.
To help speed up the time it takes to recreate files like dependencies, GitHub can cache files you frequently use in workflows.
Artifacts versus dependency caching
Artifacts and caching are similar because they provide the ability to store files on GitHub, but each feature offers different use cases and cannot be used interchangeably.
- Use caching when you want to reuse files that don't change often between jobs or workflow runs, such as build dependencies from a package management system.
- Use artifacts when you want to save files produced by a job to view after a workflow run has ended, such as built binaries or build logs.
For more information on workflow run artifacts, see Store and share data with workflow artifacts.
Cache security
Caches are shared based on the branch or tag a workflow run uses, not on the identity of the workflow or job. See Events that trigger workflows and the GITHUB_REF for the branch used for various workflow triggers. 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.
Untrusted workflows can read sensitive cache contents, such as when a pull_request from a fork restores a cache. Poisoned caches can lead to code execution in trusted workflows. To limit the risk of cache poisoning, GitHub gives workflows that run in response to low-trust triggers read-only access to caches in the default branch's scope.
For details on cache scope, access restrictions, and best practices for using caches securely, see Dependency caching reference.
Next steps
To implement dependency caching in your workflows, see Dependency caching reference.