Cache package downloads and dependency stores

Restore package-manager downloads or dependency stores while keeping a locked install that validates the requested dependency graph.

View in Markdown

Prompt

Evaluate and apply this CI technique to my repository: Cache package downloads and dependency stores.

Restore package-manager downloads or dependency stores while keeping a locked install that validates the requested dependency graph.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/reuse-package-downloads.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Cache Go modules and build output

The first CI workflow for the project pins Go from go.mod and sets the setup action's cache input explicitly (the action caches by default in the version it uses), which restores downloaded modules and build output on later runs. Tests run with -count=1, so Go executes them every time.

Use it when: Go jobs download modules or rebuild unchanged packages on every run.
Before applying it: Key the cache on go.sum and the toolchain version, and measure restore time against a cold run on your runner.

Cache the pnpm store, in the right setup order

Linear’s SDK repository installs pnpm before setup-node and caches the pnpm store in its build, release, schema and dependency workflows, keyed on pnpm-lock.yaml.

Use it when: pnpm installs repeatedly download the same dependency content.
Before applying it: Keep the install and every check running on a cache hit; the cache shortens the download.

Cache Yarn downloads while keeping a locked install

Linear’s Zapier integration enables setup-node’s Yarn cache and installs with yarn install --frozen-lockfile, in its test job and its new release workflow.

Use it when: Yarn installs repeatedly fetch the same dependency content.
Before applying it: Point the cache at the actual lockfile, keep frozen installs, and keep untrusted runs from writing caches that privileged jobs restore.

Cache the native dependencies behind a JavaScript build

The React Native jobs already restored pnpm and Bundler caches, while the Android jobs still downloaded Gradle distributions during each run. Checkout Kit turned on the setup-java Gradle cache, keyed on the Android, React Native and sample-app Gradle and package files.

Merged 2026-05-21; the Gradle cache is on the default branch. Source

Use it when: Package-manager caches hit while native dependency setup stays cold.
Before applying it: Cache dependency stores and keep native build outputs out of the cache.

Cache Bazel downloads and build outputs

target-determinator's presubmit and release jobs now start with setup-bazel, which caches Bazelisk and downloaded Bazel versions, the external repository cache, and a disk cache for build outputs keyed per tested Bazel version. Pull request runs restore the caches without saving them, so trusted builds on main populate them.

Use it when: Bazel jobs download toolchains and external dependencies and rebuild every output on each run.
Before applying it: Restore-only pull request runs keep untrusted code from writing shared caches; a disk cache per Bazel version keeps versions apart.

Use the ecosystem’s cache integration

Stripe React Native replaced hand-maintained Gradle cache paths with gradle/actions/setup-gradle and built the Android app with --build-cache.

With full caches, the author measured new-architecture app builds at 2:34 against 8:03 and old-architecture builds at 1:42 against 3:50, across all the PR’s changes. Stripe React Native later moved these tests to another CI system in stripe/stripe-react-native#2137. Source

Use it when: Gradle cache maintenance is ad hoc, or builds never reuse cached task outputs.
Before applying it: The source PR changed caching, build flags and emulator ordering together. Measure the cache action on its own, and audit cache paths, trust scope and configuration-cache encryption.

Persist the build cache between runners

Tango added a persistent Bazel disk cache to its integration job. The same PR runs nested queries in a fresh batch-mode Bazel process and raises the outer request timeout. OPT61 is extended from dependency installs to content-addressed build outputs.

The PR reports a local pass in 81s and a successful CI integration job in 6m45s. Source

Use it when: Ephemeral CI jobs repeatedly rebuild the same inputs, or a persistent build process keeps stale state after a checkout changes.
Before applying it: Keep cache validity under the build tool's control and restrict cache writes across trust boundaries. Treat a hung build server as its own problem.

How companies used this technique

Cache Go modules and build output

Cache the pnpm store, in the right setup order

Cache Yarn downloads while keeping a locked install

Cache the native dependencies behind a JavaScript build

Cache Bazel downloads and build outputs

Use the ecosystem’s cache integration

Persist the build cache between runners

Related techniques

Persist compiler output between runs

Bake stable dependencies into runner images

Cache the directories the build actually uses

Company Playbooks

Related guides

Cache workflow dependencies

Cut repeated test setup

Share setup steps across jobs

Optimize npm installs

Optimize pnpm installs