GitHub Actions: From Zero to Production(EP6)🚀

Episode 6 – Caching & Artifacts (Faster Pipelines, Smarter CI)

So far in this series, we’ve focused on correctness:

• workflows
• runners
• actions
• secrets and environments

Now it’s time to focus on something every developer cares about:

Speed ⚡

In this episode, we’ll understand caching and artifacts — two concepts that are often confused, but serve very different purposes in GitHub Actions.

---

Why This Topic Matters

Without caching:

• every CI run downloads dependencies again
• pipelines are slow
• developers wait unnecessarily

Without artifacts:

• jobs can’t share build output
• deploy steps become messy
• pipelines break in subtle ways

A good pipeline uses both — correctly.

---

1️⃣ What is Caching?

Caching means:

Reusing data from previous workflow runs to speed up future runs

Typical things to cache:

• npm / yarn / pnpm cache
• dependency downloads
• build tool caches

Caching is about:

• performance
• efficiency
• faster feedback loops

❗ Cache is not guaranteed to exist — workflows must still work without it.

---

2️⃣ What are Artifacts?

Artifacts are:

Files produced by a job that need to be used later

Common artifact examples:

• build output (dist/, build/)
• test reports
• coverage reports
• logs

Artifacts are about:

• sharing data
• traceability
• correctness

---

3️⃣ Cache vs Artifacts (Very Important)

Aspect	Cache	Artifact
Purpose	Speed	Share files
Between runs	✅	❌
Between jobs	❌	✅
Guaranteed	❌	✅
Typical use	dependencies	build output

👉 One-line rule
Cache = speed, Artifact = share

---

4️⃣ Dependency Caching (npm Example)

❌ Without caching

Every run:

npm ci → download everything → slow

---

✅ With caching (recommended approach)

- name: Cache npm
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

Then install:

- run: npm ci

What happens:

• First run → cache miss → downloads deps
• Next run → cache hit → much faster

---

5️⃣ Why NOT Cache node_modules?

Caching node_modules is risky because:

• it’s OS and architecture dependent
• it can go out of sync with package-lock.json
• it’s very large
• failures become hard to debug

Best practice:

Cache what you download, not what you install

---

6️⃣ Uploading Artifacts (Build Job)

- name: Upload build output
  uses: actions/upload-artifact@v4
  with:
    name: build-output
    path: dist/

This:

• stores dist/
• makes it available to other jobs
• keeps it for later inspection

---

7️⃣ Downloading Artifacts (Deploy Job)

- name: Download build output
  uses: actions/download-artifact@v4
  with:
    name: build-output

Now the deploy job can use the exact files produced by the build job.

---

8️⃣ Real-World Example: Build → Deploy

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist

      - run: echo "Deploying build output"

This pattern is clean, reliable, and production-safe.

---

9️⃣ Common Mistakes 🚨

❌ Using cache to share build output
❌ Expecting cache to always exist
❌ Using static cache keys
❌ Uploading huge artifacts unnecessarily
❌ Forgetting needs: between jobs

---

Final Mental Model (Lock This In)

Cache     → reuse between runs
Artifact  → share between jobs

If you understand this distinction, your pipelines will be:

• faster
• more reliable
• easier to debug

---

What’s Next?

👉 Episode 7:
Reusable Workflows & DRY Pipelines

We’ll learn how to:

• avoid copy-pasting workflows
• centralize CI/CD logic
• scale GitHub Actions across repos

Follow along — we’re getting very close to production-level mastery 🚀

---

Thanks for reading!
Happy automating ⚡