Ci-matrix spawning too many jobs

Languages Node.js
1

When setting 2 versions of node to run a build, instead 3 jobs are generated (expected 2)

https://travis-ci.com/amclin/react-project-boilerplate/builds/132043918

language: node_js
node_js:
  - node
  - lts/*
jobs:
  include:
    - if: branch = master
    # Define the release stage that runs semantic-release
    - stage: release
      # Advanced: optionally overwrite your default `script` step to skip the tests
      # It may not needed if `npm run build` and `npm test` run in preversion step
      script: skip
      deploy:
        provider: script
        skip_cleanup: true
        script: npm run test:badges && npm run semantic-release
2

You have a 2-job matrix, plus a single job defined with jobs.include for a total of 3 jobs.

3

The jobs.include shows up as a 4th “release” job (and was properly skipped). Please look at the linked run which has 3 distinct jobs in the “test” group.

4

You are defining two include: jobs, one with - if: branch = master and the other with - stage: release onwards.

(Now put two and two together :slight_smile: )

5

Right. You have 3 jobs (2 from the top level matrix, plus 1 in jobs.include) defined in the default Test stage. The one in jobs.include only has the if key, but it’s a separate job, and it inherits all the other properties from the top level and executes it. (node_js is an array, so the first value is used.)

I don’t know the shape of the desired build configuration, so it is very difficult for me to advise how to “fix” it.

6

Thanks, this helps. Travis documentation isn’t very clear on the point of conditionals and how to structure them so they aren’t considered separate jobs.

My expected build should have 2 “test” jobs (one for each version of node), and one “release” job that only runs when the branch = master. Based on this conversation I think I know what that looks like, and I’m testing this config which appears to do the trick:
https://travis-ci.com/amclin/react-project-boilerplate/builds/132185767

language: node_js
node_js:
  - node
  - lts/*
jobs:
  include:
    # Define the release stage that runs semantic-release
    - stage: release
      if: branch = master
      # Advanced: optionally overwrite your default `script` step to skip the tests
      # It may not needed if `npm run build` and `npm test` run in preversion step
      script: skip
      deploy:
        provider: script
        skip_cleanup: true
        script: npm run test:badges && npm run semantic-release

What would be ideal is if I can skip the entire “release” stage and not trigger any jobs (rather than generating a job that gets cancelled after installing Node).

7

The first example in this doc shows how to reject all build requests that do not satisfy the branch condition. If you move the if condition to the stage key (the second example), the stage for which this if key matches will be removed. If you move it to the jobs.include level (the third example), the job that matches the if key will be rejected. I think this is a reasonable explanation of what happens to the if key, but if you have suggestions on how to improve it, we welcome your suggestions (use the button on the upper right corner!).

8

I think what tripped me up is I originally put it in jobs:include (like the 3rd example) but my IDE complained that an array was expected there because I already had a stage defined:

jobs:
  include:
    if branch=master # this reported as an error because it wasn't an array
    - stage:release

The jobs:include example uses an anonymous job, which is confusing when trying to build the mental model differentiating jobs from stages