Travis currently offers a set of automatically-expanded keys (
jdk, …), whose availability depend on the build environment.
The only way an end user has for a customized build matrix is to rely on
env. Say, however, that I have a custom build I want to test for all combinations of two environment variables
BAR, whose possible values are respectively
As far as I know, the only way this could be currently done in Travis is by explicitly including all the combinations:
env: jobs: - FOO=1 BAR=a - FOO=1 BAR=b - FOO=1 BAR=c - FOO=2 BAR=a - FOO=2 BAR=b - FOO=2 BAR=c - FOO=3 BAR=a - FOO=3 BAR=b - FOO=3 BAR=c
is this correct?
If so, I believe it’s an important limitation on matrices.
I would propose to provide a standard way for generating expansions for environment variables.
One possibility could be:
env: jobs: - name: FOO values: [1, 2, 3] - name: BAR values: [a, b, c]
This would expand to a 3x3 matrix. If this tooling is introduced, a better filtering could be of use for
jobs.exclude. Let’s say that we have:
env: jobs: - name: FOO values: [1, 2, 3] - name: BAR values: [a, b, c] - name: BAZ values: [d, e, f, g, h, i]
This is a big 3x3x6 matrix. But let’s say that when
FOO=1, then only
BAZ=i make sense, and when
This would make a 3x4+6+3x6 build.
jobs: exclude: - env: - name: FOO is: 1 # is: single-value match - name: BAZ in: [h, i] # in: multi-value match - env: - name: FOO in:  # same as is: 2 - name: BAR not: [b] # reverse match
What do you think?