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 can run in an environment built from scratch.
To set up the system for your build, you can use the
sudo command to install
packages, to change configuration, create users, and so on.
Builds have access to a variety of services for data storage and messaging, and can install anything that's required for them to run.
The Build Machine
On the Linux platform, builds have 3 GB of memory available. Disk space is limited, but there's no fixed limit per build. Builds have up to two cores available (bursted).
CI environment OS
Travis CI virtual machines are based on Ubuntu 12.04 LTS Server Edition 64 bit.
The containers running the tests have IPv6 enabled. They don't have any external IPv4 address but are fully able to communicate with any external IPv4 service.
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 VM images
All VM images have the following pre-installed
- A (very) recent Git release from the Peter van der Does' Git PPA
- Mercurial (official Ubuntu packages)
- Subversion (official Ubuntu packages)
Compilers & Build toolchain
GCC 4.6.x, Clang 3.2.x, make, autotools, cmake, scons.
curl, wget, OpenSSL, rsync
Go compiler/build tools 1.0.3, 1.1.1, and 1.2
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).
- MySQL 5.5.x
- PostgreSQL 9.1.x, 9.2.x and 9.3.x
- SQLite 3.7.x
- MongoDB 2.4.x
- Redis 2.8.x
- Riak 1.2.x
- Apache Cassandra 2.0.x
- Neo4J Community Edition 1.7.x
- ElasticSearch 1.1.x
- CouchDB 1.3.x
Headless Browser Testing Tools
USER=travis(do not depend on this value)
HOME=/home/travis(do not depend on this value)
JRUBY_OPTS="--server -Dcext.enabled=false -Xcompile.invokedynamic=false"
Additionally, Travis CI sets environment variables you can use in your build, e.g. to tag the build, or to run post-build deployments.
TRAVIS_BRANCH:For builds not triggered by a pull request this is the name of the branch currently being built; whereas for builds triggered by a pull request this is the name of the branch targeted by the pull request (in many cases this will be
TRAVIS_BUILD_DIR: The absolute path to the directory where the repository being built has been copied on the worker.
TRAVIS_BUILD_ID: The id of the current build that Travis CI uses internally.
TRAVIS_BUILD_NUMBER: The number of the current build (for example, "4").
TRAVIS_COMMIT: The commit that the current build is testing.
TRAVIS_COMMIT_RANGE: The range of commits that were included in the push or pull request.
TRAVIS_JOB_ID: The id of the current job that Travis CI uses internally.
TRAVIS_JOB_NUMBER: The number of the current job (for example, "4.1").
TRAVIS_PULL_REQUEST: The pull request number if the current job is a pull request, "false" if it's not a pull request.
TRAVIS_SECURE_ENV_VARS: Whether or not secure environment vars are being used. This value is either "true" or "false".
TRAVIS_REPO_SLUG: The slug (in form:
owner_name/repo_name) of the repository currently being built. (for example, "travis-ci/travis-build").
TRAVIS_OS_NAME: On multi-OS builds, this value indicates the platform the job is running on. Values are
osxcurrently, to be extended in the future.
TRAVIS_TAG: If the current build for a tag, this includes the tag's name.
Language-specific builds expose additional environment variables representing the current version being used to run the build. Whether or not they're set depends on the language you're using.
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
JVM (Clojure, Groovy, Java, Scala) VM images
- Oracle JDK 7u6 (oraclejdk7)
- OpenJDK 7 (openjdk7)
- OpenJDK 6 (openjdk6)
- Oracle JDK 8 EA (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.
Stock Apache Maven 3. 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/lein and Leiningen 2.3.x at
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.2 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
- 0.10.x (latest stable release)
- 0.11.x (latest development release, may be unstable)
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
installed via Perlbrew.
Those runtimes that end with the
-shrplib suffix have been compiled with
cpanm (App::cpanminus) version 1.5007
PHP VM images
PHP runtimes are built using php-build.
[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
Ruby (aka common) VM images
- 1.9.3 (default)
- jruby-18mode (1.7.8 in Ruby 1.8 mode)
- jruby-19mode (1.7.8 in Ruby 1.9 mode)
- ruby-head (upgraded every time CI passes)
- jruby-head (upgraded every time CI passes)
- ree (2012.02)
Rubies are built using RVM that is installed per-user and sourced from
These are only the pre-installed versions of Ruby. 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.3.x version (usually the most recent)
Gems in the global gem set