CI pipelines that stay fast

Anatomy

• Trigger: a push, a pull request, a tag or a schedule.
• Jobs run on fresh runners; each job is isolated, so share data through artifacts and caches, not through the machine.
• Stages order the work: lint and unit tests first (fast, cheap), then integration tests, then build and publish the artifact.
• Gates: required checks must pass before merge.
• Environments and approvals guard deployment to sensitive targets.

A pipeline example

name: ci
on:
  pull_request:
  push: { branches: [main] }
concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true
permissions:
  contents: read
jobs:
  lint-test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - uses: actions/setup-node@<full-commit-sha>
        with: { node-version: 22, cache: npm }
      - run: npm ci
      - run: npm run lint && npm test
  build:
    needs: lint-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - run: docker build -t app:${{ github.sha }} .

Keeping it fast and reliable

• Cache dependencies and build layers, keyed on the lockfile.
• Run tests in parallel and split slow suites; quarantine flaky tests and fix them, never retry blindly.
• Set timeouts so a hung job does not hold the queue.
• Make builds reproducible: pinned tools, lockfiles, no network surprises.
• Treat the pipeline as production code: review it, test changes, and give it least privilege (see the Security engineering domain).

Reading a failure