By default, Hudson builds all the possible combinations of axes exhaustively. But sometimes this is too many, or may contain combinations that don't make sense. In such a situation, you can make the matrix sparse by filtering out combinations that you don't want through a Groovy expression that returns true or false.

When you specify a Groovy expression here, only the combinations that result in true will be built. In evaluating the expression, axes are exposed as variables (with their values set to the current combination evaluated).

#### Filtering based on values

For example, let's say you are building on different operating systems for different compilers. Assume that your slave labels are label=[linux,solaris] and you have created an axis as compiler=[gcc,cc]. Any of the following expressions will filter out cc builds on linux. Depending on how you think about this constraint, you'll probably find some more intuitive than others.

Read "if both linux and cc, it's invalid" |
    !(label=="linux" && compiler=="cc")
Read "for a combination to be valid, it has to be either on solaris or on gcc." |
    label=="solaris" || compiler=="gcc"
Read "if on Solaris, just do cc" |
    (label=="solaris").implies(compiler=="cc")

#### Sparsening of the matrix

In addition to the specific filtering rules based on values, one can also use a special variable "`index`", which can be used to sparsen the matrix.

For example, `index%2==0` would cut the matrix size in half by removing one combination per every 2 combinations, in such a way that the coverage is still reasonable. Similarly, `index%3!=0` would cut the matrix size into 66% by throwing away every 1 out of 3 combinations.

It's possible to use Project cascading feature for this property. Please review this document.