Build stages result is not correct when combining build stages with matrix expansion that expands to one job only

[weitjong]

When the matrix expansion expands to two or more jobs then combining them with other build stages in the jobs.include does not cause any issues. This may sound like a nitpicking but it would be really awesome when this issue can be fixed. Imagine during experimenting one might alter the build setup by commenting off some jobs in the the job matrix then suddenly the CI build setup became broken simply because the job matrix resolve to just one job after the alteration.

[BanzaiMan]

Could you explain the problem with concrete examples?

[weitjong]

Thanks for the fast response. In this commit https://github.com/urho3d/llvm-clang/commit/deee6dfd30379e9d10bd93a478c945b287c4e0c4, if I comment off the DUMMY=1 then the combining does not take place. Travis would just throw away the the single-job matrix and only honor the jobs.include.

[BanzaiMan]

I believe this is a variation of #4681; if there is only one job in the base, matrix.include (and jobs.include) will remove this job.

In your case, there is no reason for you to define BRANCH=release_60 in the matrix; it can be inside env.global.

[weitjong]

In your case, there is no reason for you to define BRANCH=release_60 in the matrix; it can be inside env.global.

It was initially inside the env.global and having this exact issue. So I am forced to turn it into a matrix of two jobs (one real and one dummy). 😄 That's when I decided to raise this Issue here.

Alternatively, you could say, I should just have two jobs in jobs.include without using job matrix construct. That variant should always work. However, it would need me to rewrite the .travis.yaml simply because of this. Not cool.

[BanzaiMan]

It was initially inside the env.global and having this exact issue.

Oh, you're right!

[BanzaiMan]

This behavior is unlikely to change. For you, I suggest dropping env.matrix and rolling the BRANCH=release_60 job into the build stage.

[BanzaiMan]

See https://github.com/urho3d/llvm-clang/pull/1.

[weitjong]

Thanks again for the effort. I have looked at your changes. I agree with you that should work (as I have already commented before). However, it is missing my point of raising this issue. I have hit by this issue in the past after the build stage is being introduced and only care to raise the issue yesterday. What I have encountered in the past is closer to scenario I put the in the issue description. I quote below again.

"Imagine during experimenting one might alter the build setup by commenting off some jobs in the the job matrix then suddenly the CI build setup became broken simply because the job matrix resolve to just one job after the alteration."

[BanzaiMan]

I understand the issue. I explained why it behaves the way it does. It is probably possible to make this behavior more explicit to reduce confusion, since I do not think we would be changing it.

[weitjong]

I am OK if it would not be fixed. Just want to bring this surprisingly behavior to Travis attention. The issue could be workaround, provided one know what exactly what has happened.

Thanks for the PR that shows me the alternative workaround, BTW.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues