Teknium 5e685999af fix(ci): make the CI timing report unflakeable (#59818) ... The 'CI timing report' job is pure observability — it collects per-job/step durations from the GitHub API after the run and publishes an HTML gantt report + PR-vs-main timing diff. It gates nothing (all-checks-pass does not include it), yet it could redden a PR: the script makes dozens of paginated API calls with the shared repo GITHUB_TOKEN and had zero retry handling, so a single 403 (rate-limit burst when several PRs run CI concurrently) failed the job. Observed twice in a row on PR #59805. - api_get(): retry 403/429/5xx and connection errors with exponential backoff, honoring Retry-After / X-RateLimit-Reset (max 5 attempts, 120s cap). Non-transient statuses (404 etc.) still fail fast. - main(): exhausted retries raise TimingsUnavailable, caught to emit a degraded summary line + placeholder HTML artifact and exit 0 — a metrics collector must never fail the PR's checks. No timings JSON is written on the degraded path so an empty baseline can never be cached. - ci.yml: baseline-save steps on main skip gracefully when no JSON exists. Verified with a mocked urlopen harness: retry-then-success (3 attempts), exhausted-retries -> TimingsUnavailable, 404 fails fast without retry, degraded main() exits 0 with summary + placeholder and no JSON, and the --from-json happy path is unchanged.		2026-07-06 12:44:07 -07:00
..
classify_changes.py	fix(ci): only run supplychain checks in pr	2026-06-23 09:46:25 -07:00
timings_report.py	fix(ci): make the CI timing report unflakeable (#59818)	2026-07-06 12:44:07 -07:00