How many of you knew that KDE has a github mirror? The mirror is useful for github users/fans (who can for example star their favorite KDE projects), but can also be useful to KDE developers who don’t care about github. I was on of them, until today. Github features an excellent integration with Travis-CI. This means that you (as github user) get for free a Continuous Integration system already up and running, waiting for your commits.

This sounds cool, however KDE developers face a problem. The Travis virtual machines currently offer only Ubuntu, either 12.04 or 14.04. This is unfortunate for KDE projects, since up-to-date Qt and KDE libraries are not easy to install on those ubuntu versions. Basically you need to setup a 3d-party PPA and install qt and friends from there. Definitely not a fun task. (Note that this could be another interesting use case for KDE Neon!)

Yesterday I found a nice workaround to this problem: instead of building our projects on the Travis’ ubuntu, we can setup an archlinux chroot within ubuntu and we build our projects within the chroot. This means that you have complete access to all archlinux repositories and even the whole AUR!

How is this even possible?

The arch-travis script does all the dirt work. You just tell travis to execute this script, and you will end up in the archlinux chroot, where you will start the actual build of your project. You can write in the travis configuration file which packages you want to install from either the official arch repositories or the AUR.

PoC: Ark travis file

The following is the .travis.yml file I used to get working travis builds on my Ark github fork: https://github.com/aelog/ark/blob/master/.travis.yml

sudo: required

language: cpp

compiler:
  - gcc
  - clang

arch:
  packages:
    - extra-cmake-modules
    - kdoctools
    - python
    - kparts
    - kpty
    - libarchive
    - hicolor-icon-theme
    - p7zip
    - unzip
    - zip
    - lrzip
    # for GUI tests
    - xorg-server-xvfb
    # from AUR:
    - rar
    - unarchiver
  script:
    - "cmake -DCMAKE_BUILD_TYPE=Debug -DKDE_INSTALL_LIBDIR=lib -DKDE_INSTALL_USE_QT_SYS_PATHS=ON -DCMAKE_INSTALL_PREFIX=/usr ."
    - "make"
    - "sudo make install"
    # run the tests using the xvfb-run wrapper
    - "xvfb-run --auto-servernum ctest --output-on-failure"

script:
  - "curl -s https://raw.githubusercontent.com/mikkeloscar/arch-travis/master/arch-travis.sh | bash"

As you can see, the configuration file is self-explicative. I just had to install the ark dependencies and then run the usual cmake and make commands. The only tricky part was how to run the “GUI” tests (i.e. tests using the QTEST_MAIN macro). These tests require a running Xorg server, otherwise they fail with a QXcbConnection: Could not connect to display error. A simple solution is to use xvfb and run the tests through the xvfb-run wrapper. If you don’t have GUI tests, you can ignore the xvfb part. Here you can find the resulting builds.

Why should I care?

In the Ark case, I was interested in installing the optional dependencies that are currently not available on our Jenkins instance, such as rar and unarchiver. Another interesting thing could be to install clazy (from the AUR git package), so that the travis build output would show also the clazy compiler warnings. This could be useful to developers who cannot install clazy on their machines (e.g. because they have an old llvm package).

Missing bits

The main downside (for now) is that this only works on personal forks, since you need to register your github account (and your repos) on the travis website. The annoying part is that you need to sync your fork with the upstream repo, ideally after every new upstream commit. Not a great thing as we are talking about continuous integration here. I started a thread on the kde-devel mailing list, to ask whether it would be possible to enable travis with the KDE github account. If that happens, my hope is that as a project maintainer you would only need to add a .travis.yml file in your repo (if you are interested in travis builds). Everything else would happen automatically on the travis servers, with no additional overload on the KDE servers or sysadmins.

UPDATE

This is the thread I started on the devel list. As you can read in the reply by Harald Sitter, a nice workaround is to configure git to “double-push” to both the upstream repo and the github fork at once.