Split the matrix computation into its own reusable workflow

[swissspidy]

Restores #277, which was merged before it had been evaluated and then reverted in #281. This puts it back up for review on its own terms.

Prototype for evaluation — the payoff is presentational and has still not been observed working. See the caveat at the bottom before merging.

What this restores

The tree is byte-identical to #277 as merged at 862e9a3. It reverts 51aeac3 with no conflicts and nothing edited on top, so reviewing this is reviewing #277 unchanged. #280 landed after the revert and touches only reusable-issue-triage.yml; the two do not overlap and the triage fixes are unaffected. actionlint passes.

Why

A matrix becomes a collapsible group in the Actions run view only when it sits on a job declared in the workflow the run belongs to. Today the matrix is one level down, inside reusable-testing.yml, so it is not surfaced: all fifty legs appear as one flat list under a single test header.

That is also why the attempt in #274 to group the legs by moving the PHP version into the calling job's name failed, and had to be reverted in #276. There was no group to move it to — the version was not moved, it was hidden.

What this does

reusable-prepare-matrix.yml (new) holds the prepare job, moved verbatim, and exposes the two matrices as workflow_call outputs. A package can call it directly and run the legs from its own top-level jobs, which puts the matrix where the run view will group on it.

reusable-testing.yml keeps its four inputs and delegates prepare to the new workflow. It drops from 546 lines to 87. Every existing caller is unaffected; adoption of the new shape is opt-in per package.

This repository's own testing.yml adopts the fanned-out shape as the reference implementation. It refers to the workflows by local path rather than @main, so a pull request here exercises its own changes instead of whatever is on main — which closes a real gap, since until now a pull request against this repository never tested the reusable workflows it was changing.

Verified

• The extracted matrix logic produces byte-identical output to before the split: 41 functional and 9 unit legs on a pull request, 51 and 12 on the schedule.
• Both shapes pass identical with: blocks to the called workflows (asserted, not eyeballed).
• The public inputs on reusable-testing.yml are unchanged.
• actionlint clean; nesting stays within the four-level limit on both paths.

The cost, documented in the README rather than hidden

The fan-out is about thirty lines in testing.yml, which is not synced. Every future change to it has to be repeated in each package that adopts the shape. Leg names stay self-describing in both shapes, because the same called workflows serve both, so the grouped view repeats the PHP version inside the group. Worth revisiting once a grouped run can actually be seen.

The version that removes this cost is larger: derive minimum-php from composer.json's require.php and move the remaining overrides to a per-package config file, at which point testing.yml carries no per-package configuration and can be synced. Not attempted here.

Before merging

The grouping is unverified. It is reasoned from the observation that only the top-level test job produced a collapsible header in wp-cli/wp-cli-tests run 31163465254, not from seeing the grouped view work. The intended check is to merge this, convert one package's testing.yml, and look at the run.

If the grouping does not appear, this bought nothing and should be reverted. Nothing else depends on it — the split is otherwise behaviour-neutral.

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@swissspidy, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 58 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2219a8b1-5e34-42b7-9495-3ef56db3a447

📥 Commits

Reviewing files that changed from the base of the PR and between c125b7b and 80540c1.

📒 Files selected for processing (6)

• .github/workflows/reusable-functional.yml
• .github/workflows/reusable-prepare-matrix.yml
• .github/workflows/reusable-testing.yml
• .github/workflows/reusable-unit.yml
• .github/workflows/testing.yml
• README.md

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}