Skip to main content
By default, Dynamic CI decides a matrix job as a whole: every variation runs, or none does. You can opt a matrix job in to being decided by variation instead. Dynamic CI then learns each group of variations from its own history, and a pull request runs only the variations it is likely to break.

​
When to opt in

A matrix job is a good fit when:
  • Its variations do different work. Each runs on a different OS, runtime version, test suite or package group, so a change can break one and not the others.
  • It is expensive. Skipping part of it saves real runner time.
Leave a job whole when its variations split the same work differently on every run. Dynamic CI can only learn from a variation’s history if that variation does the same work each time (see below).

​
Choose the keys to split by

This is the choice that matters most. You pick one or more of the matrix’s keys. Variations that share values for those keys form a group, and each group gets its own run or skip decision, learned from that group’s own history. That history is only useful if each group does the same work from one run to the next. If suite=frontend always runs the frontend tests, its history says how often a change like this one breaks the frontend tests. If it runs a different set of tests each time, its history says nothing, and its decisions will be poor. Some more guidance:
  • Keys you don’t pick are run together. In a matrix of os × node, split by os, the Linux variations for every Node version run or skip together.
  • Fewer keys mean larger groups, which learn faster. A group needs about 10 runs in the past week before it is decided on its own history. Until then it follows the decision for the whole job.
  • Start with the key that names what breaks independently. If the macOS build fails for reasons the Linux build never sees, split by OS.

​
Opt a job in

1

Open the job's settings

In Dynamic CI → Configuration, click the matrix job to expand it.
2

Choose the keys

Under Matrix variations, choose Decide variations separately and tick the keys to split by. The section shows each key’s values with their failure rate over the past 30 days, and the groups your choice makes.
3

Set up your CI

The section’s setup checklist shows what your workflow or pipeline needs.
4

Save

In an Enforced repository, the next push is decided by variation. In Learning mode, Dynamic CI records a decision for each group and skips nothing, so you can see how the split would behave first.
Settings still apply to the whole job: Always Run and Force Run run every variation, and a path filter applies to every group.