Work out kinks in interactions between stages, allow_fail, and fast_finish

bug
build-stages

#1

In the Rust library imap, I’m looking to reduce the time it takes to get results from CI. My plan was to use a combination of build stages, allow_fail, and fast_finish. The result looks like this: https://github.com/jonhoo/rust-imap/blob/562b77255c61cd1cf813b8034d1c3d3d1325f582/.travis.yml

Some noteworthy things:

I tried to use that .travis.yml file, and ended up with this build. Two things seem to go wrong:

  • In the “test” stage, when all jobs but the Windows one had completed, Travis did not move on to the next stage (“integration”). Instead, it was waiting for the Windows job to finish. I cancelled the Windows job, and then the next stage was immediately started. I then re-started the Windows job, and then Travis again waited for it to complete before it continued to the “lint” stage. I believe this is GH issue #9677.
  • The last stage with only one job (“coverage”) takes a while to run (~16m without cache), and is allowed to fail. However, the build was not marked as successful once the last of the jobs in the “lint” stage succeeded. Furthermore, when I cancelled the coverage job, the entire build was marked as cancelled, not successful as I would have expected given that the last remaining job was marked allow_fail. I’ve filed this as GH issue #10356.

#2

+1 Same here.


#3

Now that #9677 has also been closed, this probably also becomes the tracking issue for that. Namely that Travis does not advance to next build stage when fast_finish: true.