I have started experimenting with Travis-CI for running the tasks that our homegrown CI server currently handles. There is definitely a learning curve in terms of configuration and how the various build tasks have to be tweaked to thrive within the Travis ecosystem. That all seems to be going ok. But there was one thing I really wanted Travis to do for us and that took a few minutes to figure out so I thought I'd document it here for posterity.
Travis is basically a huge map-reduce cluster for CI tasks. We were hoping to harness some parallelism to speed up our build times. The official Travis documentation for the
.travis.yml file talks about how various settings in the YAML file are permutated together to create a build matrix; the focus being on changing the environment that the tests run within. The listed examples show different ruby versions and different gem versions and that's all well and dandy. But what if you want to keep the environment the same but do something different within it like, say run specs instead of cukes or lint instead of specs. Well.... you need to make that appear to be an environmental change.
Behold, a minimum example to get Travis to run specs and cukes in separate jobs:
script: 'bundle exec rake $SCRIPT_TASK' env: - SCRIPT_TASK=spec - SCRIPT_TASK=cucumber
I feel like it would be much more natural for the expansion to happen under the
script: element such as:
script: - 'bundle exec rake spec' - 'bundle exec rake cucumber'
but, whatever, this seems to work and I can wrap my brain around it now. I just wish this use case was part of the official docs because I can't be the only person who wants to do this. There is a Github issue about it. Maybe I will stick my nose in.