GitHub Actions cache setup for Gatsby build directories between deployments

Other Questions Github
1

I’m working on a Gatsby project and want to cache build folders between runs in GitHub Actions using the cache action. My goal is to speed up builds by preserving the cache and public directories.

Here’s my current workflow:

name: Build Gatsby Site

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Setup Node
        uses: actions/setup-node@v3
      - name: Install dependencies
        run: npm install
      - name: Restore cache directory
        uses: actions/cache@v3
        with:
          path: .cache
          key: gatsby-cache-files
      - name: Restore public directory
        uses: actions/cache@v3
        with:
          path: public
          key: gatsby-public-files
      - name: Build site
        run: npm run build

The first build works fine and creates both directories from scratch. The second build finds the cached folders but doesn’t seem to update them afterward. I think my cache key strategy might be wrong but I’m not sure how to properly invalidate the cache when needed.

2

Cache keys must change when your source code changes - otherwise you’ll get stale builds. Gatsby’s .cache folder is tricky since it depends on both dependencies AND content. I’d include runner.os in the key too because Gatsby caches can be platform-specific. Try something like ${{ runner.os }}-gatsby-${{ hashFiles('package*.json', 'src/**') }}. Don’t forget restore-keys so you won’t lose everything on small changes.

3

Your cache keys are static and never change, so the cache never updates. I had the same issue last year with a similar Gatsby setup. You need dynamic cache keys that bust when dependencies or source files change. For the .cache directory, include your package-lock.json hash in the key since Gatsby’s cache depends on your dependencies. I suggest skipping caching the public directory entirely - it gets completely rebuilt, and caching it can cause stale content issues. Try using a key like gatsby-cache-${{ hashFiles('**/package-lock.json') }} with restore-keys as fallback. You’ll get cache benefits when dependencies haven’t changed, but proper invalidation when they have. My build times improved significantly after fixing this.

4

Your cache config is missing proper invalidation triggers. Those static keys like gatsby-cache-files stick around forever once they’re created - that’s why your updates aren’t showing up in new builds. I hit this exact same issue last month with a client’s Gatsby site. Don’t use separate cache actions. Instead, combine both paths in one cache step with a composite key that includes your source code hash. Try something like gatsby-build-${{ hashFiles('gatsby-config.js', 'src/**', 'package-lock.json') }}-${{ github.sha }} as your main key, then add restore-keys with less specific patterns for fallbacks. This way your cache gets invalidated when content or config changes, but you still get the performance boost when nothing’s changed. The github.sha part makes sure each commit gets its own cache entry when it needs one.