Caching Dependencies

Cache is the single biggest CI speedup

The first time you install dependencies, it takes minutes. The second time, with a warm cache, it takes seconds. actions/cache is the generic primitive; setup-* actions have built-in cache shortcuts.

Two ways to cache

1) Built-in cache (preferred)

actions/setup-python@v5 with cache: pip.
actions/setup-node@v4 with cache: npm / pnpm / yarn.
astral-sh/setup-uv@v3 with enable-cache: true.
actions/setup-go@v5 caches the Go module cache by default.

2) Generic `actions/cache`

path: — what to cache.
key: — primary key. Usually ${{ runner.os }}-deps-${{ hashFiles('**/lockfile') }}.
restore-keys: — fallback prefixes if exact key missing.

Cache pitfalls

Caches are scoped per branch. main's cache is also visible from any branch — but feature branch caches are not visible from main.
10 GB total cache size per repo. Old caches are evicted LRU.
Caching build output (dist/, .next/) saves time but introduces correctness risk. Always validate the build still works on a cold cache occasionally.

Code

actions/cache — generic example for build output·yaml

      - name: Cache Next.js build
        uses: actions/cache@v4
        with:
          path: |
            ${{ github.workspace }}/.next/cache
          key: ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-${{ hashFiles('**/*.tsx', '**/*.ts') }}
          restore-keys: |
            ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-
            ${{ runner.os }}-nextjs-

Cache is the single biggest CI speedup

Two ways to cache

1) Built-in cache (preferred)

2) Generic `actions/cache`

Cache pitfalls

Code

External links

Exercise

Progress

Comments 0

Cache is the single biggest CI speedup

Two ways to cache

1) Built-in cache (preferred)

2) Generic actions/cache

Cache pitfalls

Code

External links

Exercise

Progress

2) Generic `actions/cache`