Question
Travis CI matrix include variable precedence over env matrix
Kavi Moss
0 reputation · 13 Aug 2022, 03:05 UTC
111.9K views1
Loading…
0 reputation · 13 Aug 2022, 03:05 UTC
When a Travis CI build matrix defines the same environment variable in both the env matrix and a matrix.include entry, the documentation does not specify which value takes precedence. The current implementation appears to favor the env matrix value, but this behavior is not guaranteed and may vary between Travis CI public and Enterprise deployments. Additionally, the order of keys in .travis.yml is not preserved in a way that can be relied upon for resolution order.
The lack of a documented precedence rule makes it difficult to write predictable matrix configurations that intentionally override variables for specific jobs. Teams that depend on consistent variable resolution across builds need clarity on whether matrix.include entries are meant to extend the matrix with new combinations or to override existing env matrix values for targeted jobs.
env matrix values always win over matrix.include values for the same variable name?.travis.yml, or is it an implementation detail subject to change?env matrix variable for a single included job without duplicating the entire matrix?Travis CI expands the env matrix into a Cartesian product of all combinations, then appends each matrix.include entry as an additional job definition. When a variable name appears in both places, the include entry creates a new job rather than overriding the env value inside an existing job, so the two values are treated as separate job environments.
travisenv values win over matrix.include values for duplicate variable names..travis.yml does not affect resolution; YAML object order is not part of the build semantics and may change between Travis CI versions.matrix.exclude to remove the unwanted generated combination and matrix.include with the full desired env block..travis.yml with an env entry MY_VAR: default and a matrix.include entry that also sets MY_VAR: overridden.matrix.exclude that matches the axes producing the unwanted MY_VAR: default combination and re‑run the build; the job should disappear, showing that the pattern removes the specific generated job rather than altering a variable inside an existing job.Do not rely on any precedence rule; explicitly design the matrix so that each job has the exact environment it needs, using include for new combinations and exclude to prune unwanted ones. Verify the behavior on the specific Travis CI deployment you use before committing to a configuration that depends on variable overriding.
Use comments to ask for clarification. Post a solution as an answer.
5,960 reputation · 13 Aug 2022, 13:40 UTC
In the public SaaS platform, matrix.include entries are processed after the env matrix expansion. For a given job, any variable explicitly set in the include entry replaces the value from the matching env combination, while variables omitted in the include entry are inherited from that env row. This per-job override is consistent across recent public builds but is not documented and therefore not guaranteed.
.travis.yml with env: defining VAR=a and VAR=b, plus matrix.include: - env: VAR=override.printenv | grep VAR) to confirm which value each job receives./v3/repo/<id>/builds) to see the resolved environment per job without parsing logs.On-premise Travis CI Enterprise may run older or patched matrix logic. Validate the same test matrix against your Enterprise version before relying on the override pattern in production pipelines.