Can Travis CI matrix jobs be forced into a deterministic execution sequence?

Question

Travis CI utilizes the matrix key in .travis.yml to execute parallel job variations. While these jobs are defined in a specific order within the configuration file, the scheduler prioritizes resource utilization, which often results in non-deterministic start times and execution sequences across different builds.

This behavior introduces uncertainty when builds rely on shared side-effects, such as the state of cached directories (e.g., ~/.m2) or specific environment variable propagation. If one matrix job modifies a shared cache, the outcome of subsequent jobs may vary depending on which job the scheduler initiates first.

What mechanism exists to guarantee a strict, sequential execution order for jobs defined within a matrix? Does the allow_failures configuration impact the scheduler's priority or the order in which remaining jobs are dispatched?

Tasadduq Burney · Answer

Short answer
No. Travis CI does not expose a configuration option that forces matrix jobs to start or complete in a strict sequence. Jobs listed under the matrix key are dispatched based on available worker capacity, so the observed start order can differ between builds even when .travis.yml is unchanged.
Confirmed behavior

Travis CI matrix jobs run in parallel subject to worker availability; no start-order control exists in .travis.yml.
allow_failures only permits a job to fail without marking the build as failed; it does not influence scheduling priority or dispatch order.
Shared caches such as ~/.m2 are not updated atomically across concurrent matrix jobs, so depending on one job's cache side-effects in another job can produce flaky results.

Recommended fix
If your matrix jobs depend on each other's side-effects, run them sequentially instead of in parallel:

Define each variation as a separate top-level job in .travis.yml rather than using matrix.include or matrix.env.
Use Travis CI stages with if: conditions so later stages run only after earlier stages pass.
Consolidate the variations into a single job's script and execute the steps in the required order inside that script.

Example: sequential stages
stages:
  - name: test-java-11
    if: branch = main
  - name: test-java-17
    if: branch = main
    script:
      - ./mvn test -Djava.version=17

This assumes the Travis CI SaaS offering; self-hosted or enterprise variants may behave differently. Stage syntax also depends on your repository settings and plan, so verify against your current Travis CI documentation before merging.
Verification

Trigger two identical builds with a three-job matrix and compare job start timestamps in the Travis CI UI; differing order confirms non-deterministic scheduling.
Replace the matrix with sequential jobs or stages and confirm the order matches the configuration file across repeated builds.

One detail that could change this recommendation: do the jobs require isolated workers, or can they share a single job's script? If isolation is required, use separate jobs or stages; otherwise a single script is simpler.

Can Travis CI matrix jobs be forced into a deterministic execution sequence?

1 answer

Short answer

Confirmed behavior

Recommended fix

Example: sequential stages

Verification

Your perspective belongs here.

0 question comments