Ship every commit through one pipeline you trust

Step 1: the verify job

Start with one job, not five. Splitting lint, test, and build across parallel jobs sounds faster and usually is not: each job pays its own checkout, runtime setup, and dependency install, which is 30 to 60 seconds of pure overhead per job. Split only once a single job passes about four minutes.

# .github/workflows/ci.yml
name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  verify:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v7
        with:
          name: dist-${{ github.sha }}
          path: dist/
          retention-days: 14

Four details in there matter more than the rest. concurrency with cancel-in-progress kills the previous run when someone pushes again, which is the single cheapest way to cut your bill. timeout-minutes stops a hung test suite from burning six hours. permissions: contents: read makes the default token read-only, so a compromised dependency in a build script cannot push. And uploading dist/ means the deploy stage never rebuilds - it ships the bytes that passed.

Step 3: preview deploys on every pull request

A preview URL converts code review from reading a diff into using the feature. Cloudflare Pages, Vercel, Netlify, and Render all create one automatically from a branch; if you are deploying to your own infrastructure, a per-PR subdomain and a container is the equivalent. Read the hosting layer directory for who does this well.

The important part is what the preview job is allowed to do. Pull requests from forks run with a read-only token and no access to repository secrets, which is a feature, not a bug. Never reach for pull_request_target to work around it while also checking out the pull request head - that combination hands an attacker your secrets and is the most common way public repos get compromised.

  preview:
    needs: verify
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    environment:
      name: preview
      url: ${{ steps.deploy.outputs.url }}
    steps:
      - uses: actions/download-artifact@v8
        with:
          name: dist-${{ github.sha }}
          path: dist
      - id: deploy
        run: ./scripts/deploy-preview.sh dist
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

needs: verify is what makes this a pipeline rather than a pile of workflows. The preview never runs unless the checks passed, and it consumes the artifact the checks produced.

Handling secrets without leaking them

Masking is not security. GitHub redacts secret values from logs, but any step that can read a secret can also base64 it into an HTTP request. The controls that matter are about who can read what, not about hiding strings.

• Scope secrets to environments. Production credentials belong on the production environment, not the repository, so only jobs declaring environment: production can see them.
• Use OIDC instead of long-lived cloud keys. Set permissions: id-token: write and let AWS, GCP, or Azure trade a short-lived token for the workflow identity. There is then no static key to steal or rotate.
• Set permissions explicitly at the top of every workflow. The default token is far more powerful than most jobs need. Start at contents: read and add scopes per job.
• Pin third-party actions. First-party actions/* by major tag is fine; anything else should be pinned to a full commit SHA, because a mutable tag is a supply-chain hole.
• Never pass a secret as a command-line argument. Process listings and error traces are not redacted. Use env: on the step instead.

Where to go next

Every key used above is documented in the GitHub Actions cheatsheet, grouped by task. If GitHub Actions is not a given for your team, CI/CD tools compared sizes up GitLab CI, CircleCI, Buildkite, and Jenkins on price and lock-in.

The pipeline is only as good as the suite it runs, so pick a runner deliberately in the testing tools directory. And if the deploy target is a server you own rather than a platform, the self-hosting guide covers what to point these workflows at.