Make a red build mean something broke

A flaky failure costs more than the rerun. Each red build that turns out to be noise teaches people that red means "try again", and the next real failure gets the same treatment. These plays keep failures rare and meaningful: retry narrowly and write down what the retry hid, take known flaky tests out of the blocking path with someone responsible for them, keep new ones out, and remove causes that come from outside your code.

Confirm it in your baseline

• The Reruns column counts runs on attempt 2 or later. Above a few percent on pull_request workflows, people are rerunning until the checks pass.
• In the --json output, take runs with attempt above 1 that ended in success, and list the jobs and steps that failed or were cut off the first time. Run it from the repository root:

jq -r '.runs[] | select(.attempt > 1 and .conclusion == "success") | .id' /tmp/ci-baseline.json |
while read -r run; do
  gh api --paginate "repos/{owner}/{repo}/actions/runs/$run/attempts/1/jobs?per_page=100" \
    --jq '.jobs[] | select(.conclusion == "failure" or .conclusion == "cancelled")
      | [.name, (.steps[]? | select(.conclusion == "failure" or .conclusion == "cancelled") | .name)] | @tsv'
done | sort | uniq -c | sort -rn

• Steps that run tests point at flaky tests. Failures in "Initialize containers", checkout, install or download steps point at infrastructure. A first attempt with no jobs was waiting for approval of a fork pull request, not flaking.
• In the workflow files, look for image: lines with latest or no tag, curl or wget calls without --retry, and retry wrappers around whole test commands.

Order of work

Start with retry narrowly: it stops most reruns and produces the list of flaky tests the next play needs. Quarantine the tests that keep showing up, each with an owner and a date, then gate new tests so the list stops growing. Pinned images and resilient network calls are low risk and can ship any time. Do them first if most failed attempts died before a test ran.