On Tue, May 19, 2015 at 10:55 AM, Nick Wellnhofer <[email protected]> wrote:
> Testing against multiple Perl versions
> shouldn't be a problem with a setup like this:
>
> env:
> - CLOWNFISH_HOST=perl PERL_VERSION=5.8
> - CLOWNFISH_HOST=perl PERL_VERSION=5.10
> ...
> - CLOWNFISH_HOST=perl PERL_VERSION=5.20
> - CLOWNFISH_HOST=c
> - CLOWNFISH_HOST=go
> - CLOWNFISH_HOST=python
> - CLOWNFISH_HOST=ruby
>
> It seems that Travis uses perlbrew internally to set the Perl version:
>
> https://travis-ci.org/nwellnhof/lucy-clownfish/jobs/63065921#L84
>
> So our travis-build.sh script could simply run `perlbrew use $PERL_VERSION`
> before running the Perl tests.
The build environment Travis supplies differs depending on the value of
"language" in .travis.yml. You only get perlbrew, cpanm, and multiple Perl
runtimes if you specify "language: perl". Similarly, you only get multiple
Ruby installations if you specify "language: ruby".
It's easy enough to persuade Travis to test multiple languages using the stock
installs -- every Travis build minion supports several languages:
http://docs.travis-ci.com/user/ci-environment/#Environment-common-to-all-VM-images
* C (both GCC and Clang)
* Ruby
* OpenJDK
* Python
* Node.js
* Go compiler/build tool
* Perl (not listed but there as a stock item in Ubuntu)
But that doesn't address the issue of supporting multiple versions of each
host.
I think we may be able to get multiple versions of multiple languages using
Travis' caching:
http://docs.travis-ci.com/user/caching/#Arbitrary-directories
The idea is that we'd compile multiple versions of Perl, Python, Ruby, etc.
and then cache the dirs they live in. It seems maddeningly inefficient when
they already have this stuff set up, but it might be our best option.
This isn't an issue yet, though, because we only need to support multiple
versions of Perl for the time being.
Marvin Humphrey