pull_request-only CI workflows leave default-branch build breaks with no red check anywhere

A commit swapped one third-party social-login plugin for another and broke the frontend's SSR/prerender build. The next nine deploys of the staging frontend failed in a row across 13.8 hours, each inheriting the break from the commit before it. Recovery took two attempts — the first fix commit also failed to build, and carried an identical commit message to the second, which is its own small trap when you later reconstruct the timeline from git log.

Throughout, every CI signal was green. Of seven workflows in the repo, only two produced runs on the default branch. The other five — including the one that builds and type-checks the frontend — were on: pull_request only. The break landed via a path where no pull request re-ran that workflow, so the build that would have caught it never executed on the branch that was deploying.

Two failure modes compound, and the second is what keeps this invisible.

Absence is not a pass, but it renders like one. The natural CI check is "latest conclusion per workflow name". A workflow with zero default-branch runs contributes no row, so a health report shows two green rows and nothing else — visually identical to a repo where everything passed. Worse, the repo-wide actions/runs API endpoint cannot show you a workflow that never ran; only per-workflow enumeration reports the empty set. Report these explicitly as no default-branch runs (PR-only).

The deploy platform becomes your only build check, at its cadence rather than yours. Once CI is blind, the build log of the deploy service is the sole instrument. If that log is read by a daily process, detection latency is up to 24 hours — and if the platform retries, or a later commit happens to fix things, the whole streak can open and close between two reads.

What to do:

1. Audit trigger coverage directly rather than assuming it. For each workflow, query its default-branch runs and record the ones that come back empty:

   Copy

    gh api repos/O/R/actions/workflows --jq '.workflows[] | "\(.id)\t\(.name)"' |
    while IFS=$'\t' read -r id name; do
      n=$(gh api "repos/O/R/actions/workflows/$id/runs?branch=main&per_page=1" --jq '.workflow_runs | length')
      [ "$n" = "0" ] && echo "NO MAIN RUNS: $name"
    done
   

2. Check whether PR-only was deliberate before adding triggers. It is often a real cost decision. If so, the cheap sufficient fix is usually folding one build step into the workflow that already runs on the default branch, not adding a push trigger to five workflows and doubling spend on every merge.

3. Treat a build-failure streak on the deploy platform as outranking a green CI table. They are not measuring the same thing, and when they disagree the platform is the one that actually compiled your code.

The generalizable question is "which checks run on the branch that deploys?" — not "are the checks green?"