Jobs / matrix include are ignored if env is customized

Travis CI Discussions & Feedback
, , ,
1

I am very puzzled. I always use stages and matrix expansion with success. Now, I copied a working configuration, and it seems that matrix.include (or jobs.include) is ignores all jobs for which I customize env.
If I remove env customization, everything works as intended.

Any suggestions? See e.g. this build: only the included job with no customized env gets launched.

I can’t wrap my head around this behaviour, I use the same strategy elsewhere and it always worked.

2

Hmmm. What is env.jobs key supposed to do? Maybe I missed a memo, but this key might be interfering with the top-level jobs key (presumably via config validation). This could be a bug in our validator, and if so, it should be fixed. It would be instructive to know if turning off the config validation eradicates the problem.

3

it’s not env.jobs, what is not working is the addition of further keys on included jobs:

jobs.include is a list, if one element of such list contains env, the job does not get scheduled. Otherwise, it does. According to the documentation, this is supposed to add further keys to the global environment.
And it does, in every other build I have.

[...]
jobs:
  exclude:
    - os: *reference_os
      env: *reference_jdk
  include:
    # Not scheduled
    - stage: check
      env: NOTHING=test
      script: echo hello
    # Correctly scheduled
    - stage: check
      script: echo hello

Build validation shows two warnings:

root : deprecated key reference_os (anchor on a non-private key)


root : deprecated key reference_jdk (anchor on a non-private key)

4

Not necessarily. It is possible that env.jobs replaces what is in jobs.include.

Here’s the build with config validation Travis CI - Test and Deploy with Confidence
and here’s one without: Travis CI - Test and Deploy with Confidence

and here’s the same configuration, but without env.jobs, and config validation: Travis CI - Test and Deploy with Confidence

5

@BanzaiMan I see. I also detected a different behaviour in jobs.exclude. It used to exclude only jobs defined in env.jobs, now it also excludes jobs defined in jobs.include. This sounds consistent with the issue you supposed, if I correctly understood what you meant.

What is the expected behaviour?
I would suggest to separate matrix expansion and root.jobs. At least for my use cases, what I usually do is:

  • Prepare a test matrix using env.jobs and matrix expansion
  • use jobs.include to add additional behaviour, e.g. an initial check in a previous stage to prevent multiplatform testing if a reference platform fails (reducing resource usage and build times), or a further stage for deployment after success
  • use jobs.exclude to filter out matrix jobs that are not necessary – but I do not want to also match jobs in jobs.include, as I included them manually.