# Cut Redundant CI Combinations Before Weakening a Coverage Contract ## Claim Cut CI capacity by removing demonstrably redundant test combinations before ever touching the compatibility boundary those tests were meant to guarantee. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds when removed combinations have low unique-defect yield and a scheduled broader "sentinel" run exists to catch blind spots the trimmed matrix might create. - The order matters: this is specifically about cutting duplication *before* considering a narrower coverage contract, not an argument against ever narrowing the contract itself. - Doesn't establish which combinations are actually redundant in a given project — that requires project-specific evidence (here, PHP-version boundary testing with database pairings concentrated at compatibility edges). ## Evidence WordPress Core kept full PHP-version boundary coverage while dropping redundant database combinations, centralized a previously per-job Gutenberg download into one verified fetch, and added bounded Docker pull retries — producing roughly 52% fewer jobs and 54% fewer job-minutes per run, with rerun-to-green frequency falling from about 68% to 36%, all while the stated PHP-version coverage contract stayed unchanged. ## Links - [[Open Source Governance MOC]] — sequencing cost reduction so the compatibility promise is the last thing touched - [[3. Resources/Permanent Notes/Maintenance Visibility Functions as Funding Infrastructure]] — because applies-in; publishing this kind of before/after CI-capacity data is the same visibility move that note argues functions as a funding and staffing intervention, not just a technical writeup. - [[3. Resources/Permanent Notes/Prevented Work Is Invisible to Velocity Metrics]] — because contrasts; the bounded-retry and shared-artifact fixes here prevent infrastructure failures that a raw pass/fail count wouldn't show — this post's rerun-rate metric is a rare case where prevented work *was* made visible, precisely because someone chose to measure it. - [[3. Resources/Permanent Notes/A Deprecation Needs Adoption Evidence Before It Transfers Migration Cost]] — because contrasts; that note is about the evidence bar for removing something users depend on (language deprecation), this note is about the lower-stakes but structurally similar bar for removing redundant internal test coverage — both require evidence before removal, at different risk levels. ## Tests / falsifiers - If a periodic full-matrix sentinel run later surfaces a defect only the removed database combinations would have caught, that's evidence the redundancy judgment was wrong for that specific combination — without invalidating the general principle of evidence-first trimming. - Compare projects that publish before/after CI-capacity data against projects that trim matrices without publishing evidence; if the former don't see fewer objections or reverted trims, the "evidence before removal" order matters less than this claim assumes. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Readwise/Articles/Leaner, steadier PHPUnit runs for upcoming releases]] — Willett's matrix-trim and reliability-fix results.