The Build Environment
What This Guide Covers
This guide explain what packages, tools and settings are available in the Travis CI environment (often referred to as “CI environment”).
Travis CI runs builds in isolated virtual machines that offer a vanilla build environment for every build.
This has the advantage that no state persists between builds, offering a clean slate and making sure that your tests run in an environment built from scratch.
Builds have access to a variety of services for data storage and messaging, and can install anything that’s required for them to run.
Each build runs in one of the following four virtual environments:
- Standard (the default environment)
- Container-based (the newer environment in which
sudocommands are not available)
- OSX for Objective-C projects
- Trusty Beta (a sudo enabled, full VM per build, environment which uses Ubuntu 14.04 Trusty Tahr)
The following table summarizes the differences between the virtual environments:
|Standard||Container-based||OS X||Trusty beta|
|File System||SIMFS, which is case-sensitive and can return directory entities in random order||AUFS||HFS+, which is case-insensitive and returns directory entities alphabetically||ext4|
|Cache available||private only||private & public||private only||private only|
|Operating System||Ubuntu 12.04 LTS Server Edition 64 bit||Ubuntu 12.04 LTS Server Edition 64 bit||OS X Mavericks||Ubuntu 14.04 LTS Server Edition 64 bit|
|Memory||~3 GB||4 GB max||3 GB||7.5 GB|
All Education Pack builds use Container-based infrastructure.
The virtual machines in the Legacy environment running the tests have IPv6 enabled. They do not have any external IPv4 address but are fully able to communicate with any external IPv4 service. The container-based, OSX, and Trusty builds do not currently have IPv6 connectivity.
The IPv6 stack can have some impact on Java services in particular, where one might need to set the flag
java.net.preferIPv4Stack to force the JVM to resort to the IPv4 stack should services show issues of not booting up or not being reachable via the network:
Most services work normally when talking to the local host by either
Environment common to all Precise images
Below you will find a list of the things common to our Precise based images.
For other images, see the list below:
All VM images have the following pre-installed
- A Git 1.8 release from the git-core PPA
- Mercurial (official Ubuntu packages)
- Subversion (official Ubuntu packages)
Compilers & Build toolchain
GCC, Clang, make, autotools, cmake, scons.
curl, wget, OpenSSL, rsync
Go compiler/build tools.
Every worker has at least one version of
- Go compiler/build tool
to accommodate projects that may need one of those runtimes during the build.
Language-specific workers have multiple runtimes for their respective language (for example, Ruby workers have about 10 Ruby versions/implementations).
- Apache Cassandra
- Neo4J Community Edition
All virtual environments have recent version of Firefox installed, currently 31.0 for Linux environments and 25.0 for OSX.
If you need a specific version of Firefox, use the Firefox addon to install
it during the
before_install stage of the build.
For example, to install version 17.0, add the following to your
addons: firefox: "17.0"
Please note that the addon only works in 64-bit Linux environments.
Headless Browser Testing Tools
There is a list of default environment variables available in each build environment.
apt is configured to not require confirmation (assume -y switch by default) using both
DEBIAN_FRONTEND env variable and apt configuration file. This means
apt-get install -qq can be used without the -y flag.
The user executing the build (
$USER) belongs to one primary group derived from that user.
If your project needs extra memberships to run the build, follow these steps:
- Set up the environment. This can be done any time during the build lifecycle prior to the build script execution.
- Set up and export environment variables.
$USERto desired secondary groups:
sudo usermod -a -G SECONDARY_GROUP_1,SECONDARY_GROUP_2 $USERYou may modify the user’s primary group with
scriptwould look something like:
script: sudo -E su $USER -c 'COMMAND1; COMMAND2; COMMAND3'
This will pass the environment variables down to a
bash process which runs as
while retaining the environment variables defined
and belonging to secondary groups given above in
Build system information
In the build log, relevant software versions (including the available language versions) is show in the “Build system information”.
Go VM images
The following aliases are available, and are recommended in order to minimize frictions when images are updated:
JVM (Clojure, Groovy, Java, Scala) VM images
- Oracle JDK 7 (oraclejdk7)
- OpenJDK 7 (openjdk7)
- OpenJDK 6 (openjdk6)
- Oracle JDK 8 (oraclejdk8)
OracleJDK 7 is the default because we have a much more recent patch level compared to OpenJDK 7 from the Ubuntu repositories. Sun/Oracle JDK 6 is not provided because it reached End of Life in fall 2012.
$JAVA_HOME will be set correctly when you choose the
jdk value for the JVM image.
Stock Apache Maven 3.2.x. Maven is configured to use Central and oss.sonatype.org mirrors at http://maven.travis-ci.org
travis-ci.org has both standalone (“uberjar”) Leiningen 1.7.x at
/usr/local/bin/lein1 and Leiningen 2.4.x at
The default is 2.4.x;
/usr/local/bin/lein is a symbolic link to
travis-ci.org potentially provides any version of Simple Build Tool (sbt or SBT) thanks to very powerful sbt-extras alternative. In order to reduce build time, popular versions of sbt are already pre-installed (like for instance 0.13.5 or 0.12.4), but
sbt command is able to dynamically detect and install the sbt version required by your Scala projects.
Erlang VM images
Erlang/OTP releases are built using kerl.
travis-ci.org provides a recent version of Rebar. If a repository has rebar binary bundled at
./rebar (in the repo root), it will
be used instead of the preprovisioned version.
Node.js VM images
Node runtimes are built using nvm.
Haskell VM images
Haskell Platform Version
Haskell Platform 2012.02 and GHC 7.0, 7.4, 7.6 and 7.8.
Perl VM images
Perl versions are installed via Perlbrew.
Those runtimes that end with the
-extras suffix have been compiled with
These also have aliases with the
cpanm (App::cpanminus) Dist::Zilla Dist::Zilla::Plugin::Bootstrap::lib ExtUtils::MakeMaker LWP Module::Install Moose Test::Exception Test::Kwalitee Test::Most Test::Pod Test::Pod::Coverage
PHP VM images
PHP runtimes are built using php-build.
hhvm is also available.
and the nightly builds are installed on-demand (as
[PHP Modules] bcmath bz2 Core ctype curl date dom ereg exif fileinfo filter ftp gd gettext hash iconv intl json libxml mbstring mcrypt mysql mysqli mysqlnd openssl pcntl pcre PDO pdo_mysql pdo_pgsql pdo_sqlite pgsql Phar posix readline Reflection session shmop SimpleXML soap sockets SPL sqlite3 standard sysvsem sysvshm tidy tokenizer xdebug xml xmlreader xmlrpc xmlwriter xsl zip zlib [Zend Modules] Xdebug
Python VM images
Every Python has a separate virtualenv that comes with
distribute and is activated before running the build.
Python 2.4 and Jython are not supported and there are no plans to support them in the future.
Preinstalled pip packages
On all versions except pypy and pypy3 have
numpy as well.
Ruby (aka common) VM images
Rubies are built using RVM that is installed per-user and sourced from
RVM is able to install other
versions on demand. For example, to test against Rubinius 2.2.1, you can use
rbx-2.2.1 and RVM will download binaries on-demand.
Recent 1.7.x version (usually the most recent)
Gems in the global gem set