Build matrix

One CI job repeated across chosen OS, runtime, architecture, or dependency versions, so compatibility claims get tested instead of assumed.

“run CI on every Node version”“test the build on mac windows and linux”“same job with different versions”“all OS and runtime combinations”“repeat one pipeline job many ways”“github actions matrix”“make sure it still works on windows”“build metrix”

What it is

A build matrix takes one CI job and fans it out across combinations such as operating system, runtime version, architecture, or dependency version. GitHub Actions calls this strategy.matrix: one job definition can become Node 20 on Linux, Node 22 on Linux, and Node 22 on Windows, all running in parallel.

Reach for a matrix when your package promises compatibility across real platforms or versions. Keep one small combination as the fast default, then add the combinations that represent supported environments and known failure boundaries.

Gotcha: dimensions multiply. Four operating systems times five runtimes times three databases creates 60 jobs before you test a single extra setting. Use include and exclude for meaningful cases, cap concurrency, and do not spend CI minutes proving combinations you do not support.

Ask AI for it

Convert the compatibility job in this GitHub Actions workflow to strategy.matrix. Test Node 20 and Node 22 on ubuntu-latest, plus Node 22 on windows-latest and macos-latest using explicit include entries. Set fail-fast: false and max-parallel: 4, expose matrix.os and matrix.node to runs-on and actions/setup-node, and include both values in each job name. Keep lint and typecheck outside the matrix so they run only once.

You might have meant

test matrixci cd pipelineci runnercontinuous integrationcross browser testing