Matrix Strategy (Retired)
Former reusable workflow that built component matrices. Kept for historical context and migration notes.
The Matrix Strategy reusable workflow has been removed from the repository. The CI and Knip workflows now discover components and execute checks sequentially inside a single job, so matrix fan-out is no longer required.
Why it was removed
- Runner pressure – Each matrix leg consumed a separate slot on the self-hosted runner, creating avoidable contention.
- Duplicate setup costs – Tooling installation, cache restoration, and secret resolution repeated for every matrix entry.
- Simpler orchestration – The new sequential jobs can coordinate discovery, execution, and reporting without cross-job communication.
Replacement strategy
- Call the change-detection workflow to gather candidate workspaces.
- Use in-job discovery logic to filter, skip, or include components based on
ci-ignores.jsonand script availability. - Loop through the resulting list inside a single job, running the relevant tooling for each component.
This pattern is implemented in both .github/workflows/ci.yml and .github/workflows/knip.yml.
When to consider matrices again
The sequential model keeps concurrency low, which is ideal for constrained runners. If a future workflow truly needs parallelism (for example, long-running end-to-end suites that must finish under a strict wall clock), a lightweight matrix could be reintroduced. For now, prefer the sequential discovery loop so documentation and automation stay aligned.