Stop waiting on Travis CI: use an explicit build matrix

Your pull request is waiting on a single job

You added Node 20 support last week, and now every push runs the test suite on Node 18, then Node 20, one after the other. Meanwhile, other branches queue behind the build. The problem is not your test speed; it is that your .travis.yml is not telling Travis CI to run those versions at the same time.

The useful takeaway: use matrix.include to define explicit language and OS combinations, and set matrix.fast_finish: true so a failed job stops the rest of the matrix from waiting.

What the build matrix actually is

Travis CI reads .travis.yml from your repository root on every push or pull request. A job is a single run of your test script. The build matrix is the set of jobs Travis creates from your language, operating system, distribution, and environment settings. Jobs run concurrently up to your account's concurrency limit; anything beyond that waits in a queue.

Worked example: Node 18 and 20 with unit and integration tests

This .travis.yml creates unit jobs for both Node versions implicitly, then adds integration jobs explicitly through matrix.include:

language: node_js
node_js:
  - "18"
  - "20"
os: linux
dist: focal
cache:
  directories:
    - node_modules
matrix:
  fast_finish: true
  include:
    - node_js: "18"
      env: TEST_SUITE=integration
    - node_js: "20"
      env: TEST_SUITE=integration

Commit the file from your terminal. You need write access to the repository:

git add .travis.yml
git commit -m "CI: add Node 18 and 20 matrix with fast finish"
git push origin main

Open the Travis CI dashboard for your repository. Expected check: the build shows four jobs instead of two. If the Node 18 unit job fails, pending jobs should be skipped rather than allowed to finish.

Risk: never commit plaintext secrets such as API keys or database passwords in .travis.yml. Store credentials in Travis repository settings or encrypted environment variables instead.

Trade-offs and limits

Every include entry multiplies job count. A large matrix can exhaust your concurrency slots, delaying other branches and pull requests. Travis CI's free and open-source plans have changed since launch, so confirm your current concurrency limit and eligibility in account settings before scaling the matrix.

Practical check: after the first run, compare the total build time in the Travis UI against your previous single-job run. If jobs sit queued for more than a few minutes, trim the matrix or remove include entries.

Start small and watch the dashboard

Begin with two language versions and one test suite. Add fast_finish: true immediately so failures do not waste time. Verify the job count matches your include list on the first run, then expand only if your concurrency limit allows.

Rollback: if the matrix causes unexpected queueing, revert the commit or remove .travis.yml to return to the previous single-job behavior.