ci-guard
Diagnose before retrying.
Classifies CI failures to make rerun decisions more informed.
Problem
Blind retries can hide failures and consume CI minutes.
My contribution
Development and maintenance of this personal project.
THE PIPELINE / SYSTEM MAP
ci-guard
A CI failure becomes a classified decision with budgets and verification.
Step 1 / 6
CI snapshot
Capture failing checks and logs before any rerun attempt.
Step 2 / 6
Classification
Distinguish branch, infrastructure, flaky test, dependency and unknown failures. Python scripts make no LLM calls.
Step 3 / 6
Retry budget
Eligible failures may retry only within per-job, per-PR and minutes budgets.
Step 4 / 6
Verify the green
A flaky test that turns green requires additional verification on the same SHA.
Step 5 / 6
Ledger & human decision
Record flakiness history; recommend quarantine when criteria apply. A person decides.
Step 6 / 6
Fix or investigate
branch_failure requires a fix; unknown requires manual log inspection. Exhausted budgets stop retries.
Fixing code, investigating and retrying are different paths.
Connections and conditions
- CI snapshot → ClassificationCollects evidence
- Classification → Retry budgetFailure eligible for retry
- Classification → Fix or investigateBranch or unknown
- Retry budget → Verify the greenFlaky turned green
- Retry budget → Fix or investigateBudget exhausted
- Verify the green → Ledger & human decisionRecords verification
Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.
Explore components or play the walkthrough.
Engineering decision
Separating transient failures from code problems reduces blind decisions.
Trade-off
Classification needs observable rules and care with false positives.
Evidence
Python scripts classify failures and apply retry budgets without LLM calls or API keys, according to the public project contract.
Project documentation ↗