What it does
Pulls every FAILED/REGRESSION case from the latest Jenkins build via the REST API (or a passed URL / local JUnit fallback), diagnoses each by root cause (test defect / flaky / env / product defect), fixes the test/flaky/env causes, and re-runs only the previously-failed set locally as confirmation testing. Real product defects are escalated via /qa:triage, never silenced.
When to use it
To triage and fix a red Jenkins build end-to-end.
Prerequisites
ci.jenkins_url + ci.jenkins_job in config and JENKINS_USER/JENKINS_API_TOKEN in env — or a build URL — or local JUnit artifacts; the configured runner.
Output
Test Execution Log / Test Results (ISO/IEC/IEEE 29119-3) of the local re-run, plus Incident (Defect) Reports for escalated product defects via /qa:triage.
Mechanics
How it works
- Pull the latest Jenkins testReport by precedence (URL -> config -> local JUnit); state N failed cases
- Extract only FAILED/REGRESSION cases as a numbered list with traces
- Diagnose and classify each (test defect / flaky / env / product defect)
- Fix the test/flaky/env causes with minimal trace-rooted changes
- Re-run only the previously-failed set locally (confirmation testing), cap 3 attempts/case
- Report counts; escalate product defects via triage, route flakiness to flaky-hunt
Why it works
The theory behind it
Execution + defect management + confirmation testing (CTFL §1.4, §2.2, §5.5). Re-running only the previously-failed set is confirmation testing by definition.
CTFL v4.0 §1.4 · §2.2 · §5.5 · §6 · Quality in DevOps · CT-TAE
Example
See it in use
> /qa:fix-jenkins https://jenkins.acme.io/job/shopease/job/main/482/✓ Correct when It pulls only FAILED/REGRESSION cases, fixes by root cause, re-runs those locally to green, and escalates real defects via triage.
Related commands
Used by