Build Environment Overview

This guide provides an overview on the different environments in which Travis CI can run your builds, and why you might want to pick one over another.

Virtualization environments #

Each build runs in one of the following virtual environments.

Linux #

Travis CI supports two virtualization types for Linux builds: ‘full VM’ and ‘LXD’. On top of that, Linux builds can be run on multiple CPU architectures.

Full VM #

This is sudo enabled, full virtual machine per build, that runs Linux

• Slow spin-up (increased build time compared to LXD container) yet without any limitations.
• It has a fixed amount of vCPUs and RAM assigned.

LXD container #

This is a sudo-enabled LXD container build environment, as close to a virtual machine as you can get in the container world. A Linux environment is run within an unprivileged LXD container.

• Fast spin-up (decreased build time when compared to full VM), yet some limitations do apply
• It starts with min 2 vCPUs, and if there is more computing time available, the host can dynamically assign it to speed up your build

Choose a Virtualization type #

For the majority of cases, whenever available, we recommend using LXD-based containers.

Use full VM only if LXD is not available or you need

• privileged fs access
• specific system call interception
• hugepages support (subject to changes on short notice)

The table below sums up the available Ubuntu environments and virtualization type per CPU architecture:

LXD compliant OS images for arm64 are run on AWS and in Packet. LXD compliant OS images for IBM Power and Z are run in IBM Cloud. For more information see Building on Multiple CPU Architectures.

You can select Linux virtualization type by setting a virt tag to either vm or lxd. See relevant .travis.yml examples below.

macOS #

A macOS environment for Objective-C and other macOS specific projects

Windows #

A Windows environment running Windows Server, version 1803.

Virtualization Environment vs. Operating System #

The following table summarizes the differences across virtual environments and operating systems:

Available disk space is approximate and depends on the base image and language selection of your project. The best way to find out what is available on your specific image is to run df -h as part of your build script.

Define the Environment’s Infrastructure #

Usually, knowing the virtualization environment characteristics from the table above is sufficient.

But, if you do need more detail, you have one of these two questions:

• you want to see what infrastructure a finished build ran on.
• you want to determine what infrastructure a particular .travis.yml configuration will run on.

For finished builds #

To see what infrastructure a finished build ran on, look at the hostname at the top of the build log:

if it contains:

• aws → the build ran on Amazon Web Services (AWS).
• gce → the build ran in a virtual machine on Google Compute Engine.
• wjb → the build ran on macOS.
• 1803-containers → the build ran on Windows.
• lxd-arm64 → the build ran within an LXD container on Arm64-based infrastructure (currently delivered by Equinix Metal, formerly known as Packet).
• lxd-ppc64le → the build ran within an LXD container on Power-based infrastructure (currently delivered by IBM).
• lxd-s390x → the build ran within an LXD container on Z-based infrastructure (currently delivered by IBM).

If instance, right under the hostname contains ec2 → the build ran within an LXD container or as a ‘full VM’ on AWS Arm64 Graviton2 infrastructure.

For particular .travis.yml file configurations #

• Our default infrastructure is an Ubuntu Linux (os: linux) virtual machine running on AMD64 architecture (arch: amd64), on Google Compute Engine. You can specify which version of Ubuntu using the dist key.

• Using os: osx, setting a version of Xcode using osx_image:, or using a macOS specific language such as language: objective-c routes your build to macOS infrastructure.

• Using os: windows routes your build to Windows infrastructure.

• Using arch: arm64 routes your build to Arm-based LXD containers. You can specify which version of Ubuntu using the dist key.

• Using arch: arm64-graviton2 routs your build to Arm-based infrastructure. You must specify target virtualization environment (virtual machine or LXD container) using virt key.

• Using arch: ppc64le routes your build to IBM Power-based LXD containers. You can specify which version of Ubuntu using the dist key.

• Using arch: s390x routes your build to IBM Z-based LXD containers. You can specify which version of Ubuntu using the dist key.

• Using arch: arm64-graviton2 routes you to the AWS environment powered by Arm64 Graviton2 CPUs. Available Ubuntu versions depend on the virtualization type (lxd/vm).

• If you have set os: key to target Linux environment, you can further specify the environment type using the virt: key.

To avoid mistreated keys you can validate your .travis.yml file using the Build Config Validation.

Partner Queue Solution #

With the introduction of a new billing system in Travis CI, the IBM and part of the ARM64 infrastructures are kept available free of charge for OSS as a part of the Partner Queue Solution. For more details see Billing Overview - Usage based Plans - Credits.

Linux Examples #

AMD64 builds #

arch: amd64          # optional, this is default, routes to a full VM
os: linux            # optional, this is default
dist: focal          # or bionic | xenial | trusty | precise with xenial as default

Arm64 builds #

arch: arm64           # LXD container based build for OSS only
os: linux             # required for arch different than amd64
dist: focal           # or bionic | xenial with xenial as default

arch: arm64-graviton2 # in AWS over Graviton2 CPU
virt: lxd             # required, routes to an LXD container
os: linux             # required for arch different than amd64
dist: focal           # or bionic | xenial with xenial as default
group: edge

arch: arm64-graviton2 # in AWS over Graviton2 CPU
virt: vm              # required, routes to a 'full VM' instance
os: linux             # required for arch different than amd64
dist: focal
group: edge

The IBM Power and Z builds #

arch: ppc64le         # The IBM Power LXD container based build for OSS only
os: linux             # required for arch different than amd64
dist: focal           # or bionic | xenial with xenial as default

arch: s390x           # The IBM Z LXD container based build for OSS only
os: linux             # required for arch different than amd64
dist: focal           # or bionic | xenial with xenial as default

Linux: Security and LXD Container #

These limitations are not applicable if your builds are run on virt: vm (virtual machine) environment. However, please note that VMs start slower and have fixed computing power assigned compared to containers (LXD).

Access Privileged File Systems #

Due to security reasons, builds run in LXD containers will be denied access to privileged filesystems and paths - a privileged container with write access to e.g. /sys/kernel/debugfs might muddle an LXD host.

As a result, for instance, a command in .travis.yml like:

sudo docker run --privileged --rm -t -v /sys/kernel/debug:/sys/kernel/debug:rw

would result in an error.

Also have a look at the Github issue relevant to the topic and the LXD apparmor setup for more details.

System Calls Interception #

If you run into a message like:

System doesn’t support syscall interception

It most probably means a system call interception is outside of the list of the ones considered to be safe (LXD can allow system call interception if it’s considered to be safe).

Linux: Hugepages Support #

As of now, Travis CI is not configured to allow hugepages within unprivileged containers. This may change on short notice.

The unprivileged containers access to hugepages is added by the great Linux and LXD teams. To understand what needs to be addressed in order to avoid memory issues with LXD containers, please look at the resources below:

• LXD 3.22 release notes

VM Instance Size #

If you need more than the default 2vCPU and RAM, you can run a build on a larger instance size. Variable instance sizes are available only for ‘full-vm’ build jobs. All you need to do is type the appropriate instance size to your .travis.yml using the following tags and one of the available values:

vm:
  size: [large|x-large|2x-large]

Available instance sizes can be selected for the following build jobs:

• OS is Linux, FreeBSD or Windows
• CPU architecture is amd64

In other cases you may find your job rerouted to the default Linux queue in Google Cloud. The support for larger instances of arm64 Graviton2 is on the way.

Please note, that the usage of VM instance sizes requires some credits to be available in the user’s account. Read more in our billing overview.

Each tier of instance size delivers more vCPU and RAM resources available at your discretion. The default one is ‘medium’, which is mapped to any basic instance in our infrastructure providers, usually being 2vCPU and around 4 or 8 GB of RAM. One does not need to call it out explicitly, the ‘medium’ is assigned automatically to your build job.

GPU VM Instance Size #

You can choose to run your GPU builds on various GPU “sizes”. All you need to do is type the appropriate instance size to your .travis.yml using the following tags and one of the available values:

vm:
 size: [gpu-medium | gpu-xlarge] #new values in the schema for existing key

Available instance sizes can be selected for the following build jobs:

• OS is Linux
• CPU architecture is amd64

Please note that the usage of GPU VM instance sizes requires available credits in the user’s account. Read more in our billing overview.

Deprecated Virtualization Environments #

Historically, Travis CI has provided the following virtualization environments.

• Trusty Container-based environment: was available between July, 2017 and December, 2018.
• Precise Container-based environment: was available between December, 2014 and September, 2017.
• Legacy Linux environment: was available until December, 2015.

If you’re trying to use sudo: false or dist: precise keys in your travis.yml, we recommend you remove them and switch to our current Xenial Linux infrastructure.

Build Config Reference #

You can find more information on the build config format for Operating Systems in our Travis CI Build Config Reference.