Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Experiment with modularizing Travis jobs
Resolves typelevel#2570 This sets up the Cats Travis build to use Travis's stages feature and modularizes the Travis jobs. This probably introduces a little bit of extra overhead since each new job needs to spin up a virtual machine and pull the cache. However, I think that this extra overhead is offset by a number of factors (see further below). We are now only publishing code coverage reports for the default Scala version (currently 2.12.x). I don't think that publishing multiple coverage reports for the same commit even has well-defined results, and I suspect that we didn't really mean to do that. Since running the tests with code coverage is probably the most time-consuming thing that the tests do, this is a significant time saver. Each individual job has a smaller run duration (usually < 20 min). This means that if an individual job does fail and we have to restart it, we are waiting for a smaller amount of time than previously. In theory at least, there's more ability for parallelization. In testing on my fork, it looks like Travis tends to run 3 to 5 jobs in parallel. So since we already had that many jobs before, this may not be much of a win. Modularizing the build allowed for a few small installation optimizations (only installing jekyll for the docs job, only installing node.js for the JS builds, etc). Lastly, I'm hoping that this sets the stage to move toward releasing via [sbt-ci-release](https://github.com/olafurpg/sbt-ci-release) instead of requiring a maintainer to awkwardly publish from their personal computer. This new Travis configuration allows us to run a bunch of tests/validation in parallel and then if all goes well, move on to a stage that is responsible for releasing. Since each job has its own time limit, we can probably avoid previous problems of releasing from Travis causing builds to take too long. Note that Travis stages have awkward interactions with the build matrix, so I'm now using YAML anchors (essentially templates) to reduce duplication rather than the build matrix. This allows for finer-grained control that I think works out pretty nicely.
- Loading branch information