Build your open source projects on IBM Power and IBM Z CPU architecture

Last month, we introduced the capability to build open source software for multiple CPU architectures. Today, we’re excited to extend that capability beyond arm64 and amd64 to using the same Travis CI infrastructure to seamlessly build on IBM Power and IBM Z architectures!

Thanks to the partnership with the Canonical, IBM Power and IBM Z teams we can share this awesome feature with all of you in this early release.

Build with Travis: Multi CPU Architectures

What you can expect from this Alpha release

Would you like to start testing out IBM Power and IBM Z CPU architecture? This is what you need to know:

  • It’s LXD based and your build jobs are run within an LXD container.
  • At this point, it’s available for your open source projects only. We’re waiting to hear from you if you’re interested in testing your private projects too.
  • Your open source projects can run on travis-ci.org or travis-ci.com
  • The initial infrastructural build capacity has a total of 40 concurrent jobs on IBM Z (s390x) and 64 concurrent jobs on IBM Power (ppc64le) split between travis-ci.org and travis-ci.com.

How to get started

IBM Power

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

os: linux
arch: ppc64le

Alternatively, you can use a legacy tag dragged from our experimental implementation, which will be honored as long as experimental job queues on travis-ci.org are running:

os: linux-ppc64le

We recommend using arch: ppc64le and os: linux though to make sure your jobs run smoothly.

Some examples of build jobs using IBM Power CPU architecture can be found here:

IBM Z

To start running your builds on IBM Z CPU architecture modify your .travis.yml file by adding the arch key:

os: linux
arch: s390x

Running both IBM Power and IBM Z at the same time

To run your build on IBM Power and IBM Z simultaneously, add the following arch key to your .travis.yml file:

os: linux
arch:
  - ppc64le
  - s390x

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

matrix:
  include:
   - os: linux
     arch: ppc64le
   - os: linux
     arch: s390x

is the right 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. Check out linuxcontainers.org for more information.

For more detailed instructions, go to our docs.

LXD

LXD is a Linux container manager allowing for a ‘lightweight VM container’ user experience. It’s one of the available containerization solutions. The main difference between LXD and e.g. Docker is that LXD runs an upstart/systemd like process inside the container and is automatically ready to be a full VM-alike environment, while still benefiting from being a container.

Why LXD?

LXD gives you “full OS” inside a container and it makes a lot of things linked to VM-like management easier without much additional effort required.

  • As builds are run within LXD containers, the build jobs are faster to start when compared to traditional VM-based instances. This is due to the advantages of containerization (an Ubuntu-based build job starts fast an LXD container, within which build activities are executed).
  • Our team was able to use the existing “full-VM approach” and adapt it only where needed to utilize LXD.
  • It’s very light on CPU and memory at the same time when compared to a traditional VM.

Given that Travis CI runs your builds and tests in virtual machines that are really close to actual production servers and LXD is a type of containers as close to virtual machine user experience as possible while being a bit faster, this is why we finally picked up LXD for the containerization process of Linux builds.

Are there any constraints?

VM-alike containerization is a very effective and convenient tool, however, there are also constraints existing at the moment, which may affect some build/testing scenarios:

  • Build job can’t access privileged fs - a general security constraint preventing host-wide access from within a container (see LXD apparmor profile creation code for more details)
  • Build job can’t enable hugepages within LXD container - this is something that may change in the future, yet it depends on potential Linux kernel changes, which is something that needs to be reviewed and developed.
  • Syscall interception support - only system calls considered as safe. We will be working on overcoming these limitations in the coming months.

How you can help improve things

We’re waiting to hear from you! Please share your suggestions and questions via the forum.

If you’d like to build your private projects on IBM Power or IBM Z too, let us know on the forum or email our support team!