← All guides

Gate your CI on config waste (a ratchet for GitHub Actions hygiene)

Config waste creeps back. Someone copies a workflow without a timeout, a new matrix axis lands, a cache line gets dropped in a refactor — and nobody notices, because nothing fails. The fix is the same one you use for test coverage: a gate. Fail a check when the number gets worse.

The scorecard as JSON

Every public scorecard is available as data — no auth, no install:

curl -s https://gitspider.com/api/v1/scorecard/OWNER/REPO

The response carries findings (kind, workflow, estimated wasted minutes), run counts, failure rate, and wall-clock CI minutes for the last 30 days. Two honesty notes baked into the field names: minutes are ci_minutes_wall_clock, and the dollar figure is est_cost_usd_private_equivalent — public repos pay $0.

A weekly gate in ~15 lines

Scheduled, not per-PR — config waste moves slowly, and the endpoint serves cached scans (up to 24h old), so a weekly cadence matches the data:

name: CI config gate
on:
  schedule:
    - cron: '0 9 * * MON'
  workflow_dispatch:
jobs:
  gate:
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - name: Fail if config findings grew
        run: |
          MAX_FINDINGS=3
          COUNT=$(curl -sf "https://gitspider.com/api/v1/scorecard/${{ github.repository }}" | jq '.findings | length')
          echo "config findings: $COUNT (max allowed: $MAX_FINDINGS)"
          test "$COUNT" -le "$MAX_FINDINGS"

Set MAX_FINDINGS to your current count and ratchet it down as you fix things — the same ratchet pattern as coverage thresholds. Gate on minutes instead if you prefer: jq '[.findings[].est_wasted_min_per_month] | add // 0'.

The fine print

• Public repos only — the endpoint serves the public scanner's cache. A repo nobody has scanned returns 404 with a scan-it-first hint; visit the scorecard once (or let your README badge traffic do it) and the cache stays warm.
• Cached, not live — up to 24 hours old by design. Right for a weekly gate; wrong for a per-commit check.
• Rate-limited per IP — a scheduled job is nowhere near the cap; a per-PR matrix hammering it would be.
• Detector updates can move the count — when we improve detection, findings can change without your config changing. The scorecard's history strip marks those transitions; treat a surprise jump as "look", not "revert".

Why bother

Because every finding on the scorecard was once a diff someone approved. A gate turns "we should clean that up sometime" into a red check with a name attached — the only mechanism that has ever kept config debt from growing back. Check your current count on your scorecard, set the ratchet, forget about it.