Anatomy of a Pipeline (Stages, Jobs, Steps, Runners)

📌 Definition:

📖 Detailed Explanation:

Understanding this hierarchy is foundational because every CI system (GitHub Actions, GitLab CI, Jenkins) uses the same shape with different names. A stage groups related work and usually gates the next: tests only run after the build succeeds. Jobs within a stage typically run in parallel on separate runners, which is how you fan out browser or shard combinations. Steps run sequentially within a job and share its filesystem and workspace. Runners are ephemeral by default — each job starts on a clean machine/container, so anything one job needs from another (a built artifact, a coverage file) must be explicitly passed via artifacts or caches, not assumed to persist. This ephemerality is the single most common source of confusion for people new to CI.

🔑 Key Points:

• Hierarchy: pipeline → stages → jobs → steps, run on runners
• Stages gate progression (test after build); jobs in a stage run in parallel
• Steps run sequentially and share the job's workspace/filesystem
• Runners are ephemeral — each job gets a clean machine by default
• Cross-job data (artifacts, caches) must be passed explicitly, never assumed

🌍 Real-World Example:

📎 Code Example:

# GitHub Actions — stages expressed via job dependencies (needs:)
jobs:
  build:                     # stage 1
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - uses: actions/upload-artifact@v4
        with: { name: dist, path: build/ }

  test:                      # stage 2 — runs only after build
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/download-artifact@v4
        with: { name: dist, path: build/ }
      - run: npm ci && npm test