Caching Dependencies for Faster Builds

Most CI time is spent downloading and installing the same dependencies on every run. Caching stores them between runs so subsequent builds reuse the work, often cutting pipeline time dramatically.

GitHub provides actions/cache. You give it a path to cache and a key that identifies the cache entry. On a hit, it restores the path; otherwise it saves it after the job.

The key should change only when the cached content should change. Hashing the lockfile is ideal: a new lockfile means new dependencies, so a new cache entry is created.

restore-keys provides fallback prefixes. If the exact key misses, the action restores the most recent cache whose key starts with a prefix, giving a partial warm start.

On an exact key match you get a cache hit and the path is restored. On a miss, the job runs normally and the cache is saved at the end using the primary key, ready for next time.

The language setup actions have caching built in. For Node, setup-node with cache: npm handles the dependency cache for you, no separate cache step needed.

Cache package manager download directories, not the installed node_modules when possible, because download caches are portable and the install step still verifies integrity.

• Node: ~/.npm
• Python: pip cache
• Java: ~/.m2 or Gradle caches

Caches are scoped to a branch (with fallback to the default branch) and have a size limit per repository. Unused caches are evicted over time, so design keys that churn cleanly.

If your key never changes, you can serve outdated dependencies. Always tie the key to the lockfile hash so updates invalidate the cache automatically.

In matrix builds across OSes or versions, include runner.os and the version in the key so each variant gets its own correct cache instead of clashing.

Compare job durations before and after caching, and watch the cache-hit indicator in logs. A consistently low hit rate signals a key that changes too often.

Test your understanding of dependency caching.

You sped up CI with dependency caching: the actions/cache action with a lockfile-hash key and restore-keys fallback, built-in caching in setup actions, choosing what to cache, including OS/version in matrix keys, and avoiding stale caches by tying the key to the lockfile.