CI/CD Pipelines (GitHub Actions)

Concept#

GitHub Actions Workflows#

GitHub Actions allows you to automate workflows directly inside your GitHub repositories. Workflows are declared using YAML files placed in the .github/workflows/ directory:

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test-and-build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
 
      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
 
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
 
      - name: Run Tests
        run: pnpm test
 
      - name: Build App
        run: pnpm build

Key Workflow Vocabulary#

• Workflow: The automated process defined in a YAML file.
• Event: The trigger that launches the workflow (e.g. push to main, pull_request creation).
• Job: A set of steps that execute on a fresh virtual runner machine (e.g., runs-on: ubuntu-latest). Jobs run in parallel by default unless configured to depend on each other.
• Step: Individual commands or actions to execute sequentially within a job.

Caching Dependencies#

Downloading package dependencies on every single workflow execution is slow and wastes network bandwidth. To cache dependencies, use setup actions with built-in caching parameters (like actions/setup-node with cache: 'pnpm'), which hash lockfiles to restore caches instantly.

Common Mistakes#

1. Hardcoding API secrets in configuration files#

Hardcoding API tokens or access keys directly in your .github/workflows/main.yml exposes them to anyone with read access to the repository. Always use GitHub Secrets and refer to them securely:

env:
  API_KEY: ${{ secrets.PROD_API_KEY }}

2. Not pinning action dependency versions#

Referencing action dependencies via wildcards (like uses: actions/checkout@master or latest) is risky because upstream changes in the action repo can break your build overnight. Always pin dependencies using major versions (e.g. @v4) or exact commit SHA hashes.

Best Practices#

• Parallelize Jobs: Separate lint, unit testing, and building into separate jobs that run in parallel to minimize pipeline turnaround times.
• Fail Fast: Position cheap jobs (linting, typechecking) before slow integration/visual tests using the needs configuration tag:

  jobs:
    lint:
      runs-on: ubuntu-latest
    test:
      needs: lint # Only runs if lint succeeds
      runs-on: ubuntu-latest

• Limit Workflow Triggers: Configure path filters (paths-ignore or paths) to prevent pipelines from running on minor markdown changes: