Quality Gates That Don’t Suck: Paved-Road Automation That Stops Technical Debt at the Pull Request

The PR Queue That Turned Into a Dumpster Fire

I’ve watched this movie at three companies in the last five years: AI-assisted coding helped velocity—until the bills came due. We had eslint warnings silenced, @ts-ignore littering the codebase, flaky test suites that were “green enough,” and a backlog of Dependabot PRs nobody wanted to merge. Release trains slowed. Incidents ticked up. The same hot files kept paging us at 2 a.m.

We didn’t need another platform. We needed paved-road quality gates that stopped the worst debt from landing in main. Not bespoke. Not a six-month SonarQube rollout. Just opinionated defaults that run on every PR and block merges when the basics aren’t met.

Here’s the approach that actually works, the configs we ship, and where the cost/benefit bends in your favor.

What “Quality Gates” Actually Mean (When They Work)

A quality gate is a set of automated checks that must pass before code merges. When tuned well, they reduce:

• Rework rate (PRs reopened, commits after merge to fix basic issues)
• Escaped defects (bugs/security vulns found post-merge)
• PR review thrash (humans debating nits the linter could catch)
• MTTR by keeping the trunk healthier

The baseline paved-road gate stack:

• Style/Lint: eslint or golangci-lint with --max-warnings=0
• Type checks: tsc --noEmit for TS, mypy for Python
• Unit tests + coverage: enforce a per-PR patch coverage threshold
• SAST: semgrep with a minimal, high-signal ruleset
• Dependency scanning: Dependabot or Snyk, auto-merge low-risk patches
• Secrets scanning: gitleaks or native platform scanning
• Branch protection: required checks + CODEOWNERS on touchy areas

Everything else is optional. Start here. Add only when signal-to-noise is strong.

A Paved-Road GitHub Actions Setup You Can Copy

Below is a compact CI that blocks merges on lint, type, tests, coverage, SAST, and secrets. It uses stock Actions and open-source tools. No dashboards, no bespoke scripts.

name: ci

on:
  pull_request:
    branches: [ main ]

permissions:
  contents: read
  pull-requests: write
  security-events: write

jobs:
  node-ci:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - name: Lint (no warnings)
        run: npx eslint . --max-warnings=0
      - name: Type check
        run: npx tsc --noEmit
      - name: Unit tests with coverage
        run: npx vitest --run --coverage
      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          fail_ci_if_error: true
          flags: frontend
          verbose: true

  sast:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep scan (fail on new issues)
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/ci # curated, low-noise rules
          generateSarif: true
          baselineRef: main
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

  secrets:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }} # optional for pro

Add branch protection and required checks so none of this is “advisory.”

# Example: require status checks on main
# Requires GitHub admin token with repo:admin scope
REPO="org/repo"
REQUIRED_CHECKS='["node-ci", "sast", "secrets"]'

gh api \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  repos/$REPO/branches/main/protection \
  -f required_status_checks.strict=true \
  -f required_status_checks.contexts:="$REQUIRED_CHECKS" \
  -f enforce_admins=true \
  -f required_pull_request_reviews.required_approving_review_count=1

And make sure owners watch the right files:

# .github/CODEOWNERS
apps/payments/**   @payments-team
infra/**           @platform-team
**/*.sql           @data-team

For Go, swap eslint/tsc for golangci-lint and go test:

  go-ci:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: 1.22
      - uses: golangci/golangci-lint-action@v6
        with:
          version: v1.60
          args: --timeout=5m --out-format=github-actions
      - run: go test ./... -coverprofile=coverage.out -covermode=atomic
      - uses: codecov/codecov-action@v4
        with:
          files: coverage.out
          flags: backend

Ratcheting: Better Every PR Without a Painful Rewrite

Your codebase already has issues. Don’t block on fixing the past. Instead, ratchet quality so it only fails when a PR makes things worse.

• Patch coverage gate: enforce coverage on lines touched by the PR, not the whole repo. Codecov handles this with “patch” status checks.
• Baseline SAST: Semgrep’s baselineRef: main fails only on new findings or changed lines.
• Lint/type zeros: --max-warnings=0 only hurts if warnings already exist. If they do, add a temporary eslint . > lint.txt to count warnings, fix the top offenders, then ratchet to zero within a week.

Codecov example to require 80% overall, 90% patch coverage:

# codecov.yml at repo root
coverage:
  status:
    project:
      default:
        target: 80%
    patch:
      default:
        target: 90%
        threshold: 1% # small wiggle room

For Jest/Vitest, bake sane thresholds so the local run matches CI:

// package.json
{
  "vitest": {
    "coverage": {
      "reporter": ["text", "lcov"],
      "lines": 0.8,
      "functions": 0.8,
      "branches": 0.7
    }
  }
}

This lets teams improve incrementally without blocking urgent work—exactly how you keep adoption high.

Before/After: What Actually Changes

At a fintech we helped last year, they had 14 services, GitHub Actions on paper, and still merged broken code weekly. After a two-week rollout of paved-road gates:

• Before: 22% of PRs required follow-up fixes within 48 hours; average PR lead time 2.6 days
• After: 8% follow-ups; PR lead time 2.3 days (initial +8% bump week one, then down as reviewers trusted automation)
• Before: 4 paging incidents/quarter tied to bad merges; After: 1 per quarter
• Before: 120 open Dependabot PRs; After: <10 with an auto-merge policy on patch updates

We didn’t deploy SonarQube. We didn’t hire a “DevEx guild.” We just enforced the basics where it mattered: at the gate.

Cost/Benefit: Sonar vs Semgrep, Heavy vs Light, and When to Say No

Where we’ve seen teams burn months:

• A Big Platform First: rolling out SonarQube/Cloud with custom rules and dashboards before enforcing lint/type/test. It’s upside-down. Start with cheap signal, then graduate.
• Bespoke scripts: homegrown linters and diff coverage tools that only two people can maintain. When they leave, the gates rot.

Trade-offs in plain English:

• Semgrep vs SonarQube: Semgrep’s p/ci rules are fast and low-noise. Sonar adds deeper analysis and code smells, but also false positives and platform overhead. Start with Semgrep; add Sonar only if your false negative pain is real and you have an owner.
• Codecov vs roll-your-own diff coverage: Codecov’s patch gating is a one-line win. DIY scripts drift. Use Codecov or GitHub’s native coverage summary if/when it matures.
• Dependabot vs Snyk: Dependabot is free and fine for most OSS deps. Snyk adds license policies and transitive risk scoring—worth it if you have a regulated environment and someone to tune policies.
• Secrets scanning: gitleaks catches 90% with near-zero config. GitHub Advanced Security adds push protection and SARIF integration—worth it at scale.

Say no to:

• Org-wide “block everything” on day one. Roll out by repo or service.
• Quality gates you can’t run locally. If npm test and npx eslint don’t tell the same truth as CI, you’re going to get revolt.
• Gates that create toil for platform teams. No ticket queues to retrigger jobs, please.

Rollout Plan: Two Weeks, Real Impact

Here’s the exact sequence we run at GitPlumbers:

1. Baseline and pick the paved road
   • Decide on eslint, type checker, test runner, Semgrep p/ci, Codecov, gitleaks, and Dependabot.
   • Add CODEOWNERS for high-risk paths.
2. Wire CI and protection
   • Add the workflow above, Codecov token, and branch protection with required checks.
   • Enable Dependabot daily for app and Docker updates.
3. Ratchet, not rewrite
   • Turn on Codecov patch gating and Semgrep baselining.
   • Set lint to warnings allowed for week one, then move to --max-warnings=0.
4. Prove it with data
   • Track PR lead time, rework rate, escaped defects, and build-green rate.
   • Share a weekly dashboard in Slack. Celebrate fewer “nit” comments in reviews.
5. Expand carefully
   • Add language-specific gates for other stacks (e.g., mypy, pytest --cov-fail-under, terraform validate with tfsec).
   • Only after stability, consider heavier platforms (Sonar, Snyk) if the signal justifies the spend.

Optional infra extras that stay paved-road:

# Terraform on PRs (keeps IaC debt out)
jobs:
  terraform:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform fmt -check
      - run: terraform init -backend=false
      - run: terraform validate
      - name: tfsec
        uses: aquasecurity/tfsec-action@v1

Lessons From the Trenches

• If a gate is flaky, it’s worse than useless. Fix or remove within 48 hours.
• Don’t outsource judgment to tools. Use CODEOWNERS to route risky diffs to the people who know the domain.
• For AI-generated code, tune the gates slightly tighter: forbid @ts-ignore and require patch coverage >= 95% in high-risk dirs. We’ve used a simple eslint rule and a vitest per-project override to good effect.
• Avoid footguns: pin Action versions, cache wisely, and keep jobs under 10 minutes. Long CI turns quality gates into resentment generators.
• Make the local dev loop match CI. Ship npm scripts that mirror the gates so devs get fast feedback.

// package.json scripts
{
  "scripts": {
    "lint": "eslint . --max-warnings=0",
    "typecheck": "tsc --noEmit",
    "test": "vitest --run --coverage"
  }
}

You’ll know it’s working when PR reviews shift from “missing semicolons” to “is this the right boundary in payments?” That’s the whole point.

The Quiet Win: Fewer Debates, Faster Merges, Safer Releases

I’ve seen big-budget platform teams deliver less impact than a week of paved-road gates. The trick is resisting over-engineering. Start with the boring basics, enforce them ruthlessly, and ratchet quality forward one PR at a time.

If you’re staring at a repo full of AI-vibe code, flaky tests, and a nervous on-call rotation, we’ve done this cleanup before. GitPlumbers can drop in, wire this up, and leave you with a paved road your teams actually like to drive on.