Use a purposeful matrix

Start from the behavior you can observe. The library tests supported Node versions while the site build runs once on the production version.

A matrix should represent a compatibility promise or meaningful variation, not every available runner image. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to create a huge matrix that repeats identical evidence and exhausts minutes. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to tie each axis to documented support, use include or exclude deliberately, and keep one authoritative build. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Build a fast CI graph that preserves useful evidence without sharing mutable state accidentally. Record enough evidence that another developer can repeat the result without relying on your memory.

Write the support policy first, then derive the smallest matrix that could falsify it. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.