Multi-CPU architecture support for your builds

We’re excited to share that you can now test your open source software on multiple CPU architectures at Travis CI.

For the past few months, we’ve been working closely with the Travis CI community, the LXD team from Canonical, Arm and Packet.

Thanks to this partnership, Arm-based builds are now available to you, for free, for your open source projects. Arm-based builds are the first ones to use LXD powered containerization to run your builds.

If your public projects are targeted for Linux and Arm CPU Architecture, get started with Arm builds today!

Alpha Release

OpenSSL and Fluent Bit are already testing the multi-CPU feature, so if you are looking for examples, check out their respective .travis.yml files and the Travis CI docs.

What you can expect from this alpha release:

You can only test your open source projects at the moment. Packet infrastructure and Travis CI builds are provided to you for free. However, if you’d like to test private projects, please send us a message in the forum.
Only a limited capacity is available and we will build it up based on what we hear back from you. Initial testing capacity starts at around 60 concurrent jobs so please keep this in mind while testing Arm-based builds.
Packet is delivering the Arm64 (Armv8 compliant) infrastructure and it has been adjusted to ensure stable build times. Please grant us additional time to react when increasing capacity as it requires both companies to align.
The initial .travis.yml arch key may be adapted or extended later on. Stay tuned as we share more updates.

We’re excited to keep working on the multi-CPU feature and work with you to improve it. We heartily invite you to test out the new multi-CPU architecture and share your findings in the forum. We’re looking forward to hearing how you use it and your experience with the new feature!

How does Arm support work?

As a first step, modify your .travis.yml file by adding the arch key.

arch:
  - amd64
  - arm64

Using these two arch: keys will trigger a build matrix composed by a set of jobs with amd64 and arm64 based OS images. Please keep in mind, that for matrix.include only single key: value is valid, so

matrix:
  include:
   - os: linux
     arch: amd64
   - os: linux
     arch: arm64

is a valid approach when you want to test a specific combination of OS and CPU. This is possible only with Linux at the moment. LXD is a Linux container daemon, see linuxcontainers.org for more information.

You can identify when your job runs on the Arm-based LXD containers by checking the hostname of the worker: lxd-arm64, for example: https://travis-ci.org/openssl/openssl/jobs/591020146#L2. See the multi-CPU docs for more details on usage.

Why LXD? Docker vs LXD

LXC, the LinuX Container runtime focuses on creating and running multiple (and isolated) Linux system containers on a single control host. Docker, as an application container, originated from LXC but grew independent from it over time and became a virtualization solution to run processes.

LXD is also based on LXC, but it allows for system containers or a ‘lightweight vm-like container’. The main difference here is LXD runs upstart/systemd like process inside the container. While you can achieve similar capability with Docker, you need to enable specific systems processes each time when a docker image is run, which adds complexity and increases execution times for CI environments.

LXD, on the other hand, gives you a “full OS” inside a container and provides VM-like semantics around system containers so it can be easily operated and managed. LXD is significantly faster thanks to it all being done through containers on Linux and it’s also very light on CPU and memory at the same time.

In the past, we used Docker containers as containers for build machines at Travis CI, or Docker in docker, yet the constraints and workarounds that had to be introduced caused inconsistent build times and a lot of confusion. So we reverted back to using Docker as an app container only, and we love it!

Given that Travis CI runs your builds and tests in virtual machines that are really close to actual production servers and LXD provides a type of containers that allows doing that a bit faster, this is why we finally picked up LXD for containerization process of Linux builds instead of Docker used in unintended ways.

What’s next

Given the fast startup time and the benefits of using LXD outlined above, we are looking at expanding our usage of LXD containers for the existing build setups at Travis CI.

Stay tuned for updates as this is only the beginning of supporting multi-CPU architectures!

When you test out Arm builds in your public projects, please share your feedback with us in the community forum. We’re looking forward to hearing about your experience with multi-CPU architecture support of your builds!