Last month, we introduced the capability to build open source software for multiple CPU architectures. Today, we’re excited to extend that capability beyond
amd64 to using the same Travis CI infrastructure to seamlessly build on IBM Power and IBM Z 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
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:
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:
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
os: linux arch: - ppc64le - s390x
Using these two
arch: keys will trigger a build matrix composed of a set of jobs with
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 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.
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.