Use Jenkins as a Travis replacement for YaST


Currently we use Travis for testing commits and pull requests at GitHub.

Unfortunately there are many disadvantages which require additional work or limit us what we can run in a Travis job.

Travis Disadvantages

  • Travis is sometimes very loaded, that usually happens between 15:00 - 19:00 CET. (See the Active Linux Builds graph at the status page.) At that time range starting a build might take about 15 minutes or even more. If a build fails because of some trivial mistake you need to push a new commit and wait another 15 minutes...
  • No caching, every build starts from scratch (e.g. GCC, YaST or Ruby packages need to be downloaded and installed for each build again)
  • The biggest disadvantage is that the Travis builders use Ubuntu 12.04 LTS as the base system, this makes a lot of troubles:
    • We need to build YaST packages (and it's dependencies like libzypp, libyui, libstorage, snapper, hwinfo...) for Ubuntu 12.04. We do it in the YaST:Head:Travis OBS project. The porting required a lot of work, but fortunately thanks to the OBS support the maintenance is low.
    • Ubuntu 12.04 is very very old (3 years!, that's too much in the Linux world...), we need to update some basic system components to more recent versions, namely GCC (to compile the projects which use the new C++ features), Ruby (there is obsolete version 1.9)
    • We need to upgrade the GCC compiler one more because snapper does not build currenly
    • Old Ubunutu also means that updating the system will get more difficult in the future (e.g. backporting a newer GCC or Ruby)
    • We cannot run all checks in Travis as it's a completely different environment, e.g. we cannot test building RPM packages
    • A test might fail in Ubuntu, but pass in openSUSE (or the other way round), that means the build result is not 100% reliable
    • Debugging Travis issues is difficult, you have to install an Ubuntu VM machine and try it there (and even that might not help, I came across a failure which happened in Travis but I was not able to reproduce it in Ubuntu 12.04 VM)

Travis Advantages

  • It is hosted and maintained by the Travis CI company, that means no maintenance is needed from our side.
  • Nice integration with GitHub, it automatically reports the build status back to GitHub.

Jenkins Advantages

  • The workers can run on openSUSE, we can easily use the usual openSUSE tools for building (like osc)
  • No need for Ubuntu port, no need for backporting new packages
  • We can easily cache needed packages, the builds should be much faster
  • We can easily add more workers to build more repositories or commits in parallel
  • We can use more powerful workers (more CPU cores, more memory)


We already use the openSUSE Jenkins instance for building and submitting YaST packages. I found out that there are several Jenkins plugins which could be used to replace Travis with Jenkins:

Preliminary Work

I already tried the plugins in a testing Jenkins instance to not break the public Jenkins node. It builds the lslezak/yast-yast2 GitHub project. You can see the Jenkins build results in the branch overview page or in a testing pull request at GitHub. The details icons link to the Jenkins instance back.

Possible Problems

  • We need to properly handle the branches (i.e. use the SLE12, openSUSE or Factory build target)
  • Coveralls support? - The question is whether Coveralls can work outside Travis, this needs to be tested.

The Goal of this Project

  • Setup the Jenkins plugins at - start with the libyui project - it is a smaller project than YaST and some parts are not built in a CI at all so we can improve it
  • Define what will be executed during the build (defined in Jenkins or in the Git repository like in .travis.yml for Travis?)
  • Provide a HowTo document describing how to setup the Jenkins plugins so Jenkins can be used as a Travis replacement in other project (even outside the YaST scope)
  • If the setup for libyui project works well start then converting the YaST modules one by one

Looking for hackers with the skills:

ci jenkins travis yast

This project is part of:

Hack Week 12


  • over 8 years ago: lslezak started this project.
  • over 8 years ago: lslezak added keyword "ci" to this project.
  • over 8 years ago: lslezak added keyword "jenkins" to this project.
  • over 8 years ago: lslezak added keyword "travis" to this project.
  • over 8 years ago: lslezak added keyword "yast" to this project.
  • over 8 years ago: lslezak originated this project.

  • Comments

    • adrianSuSE
      over 8 years ago by adrianSuSE | Reply

      Do you plan to chain the builds in jenkins better? The biggest advantage of is that everybody's code out there is getting tested when they create pull request. But we do not want to run their code in house in an unprotected environement (means just chroot or VM's with open network).

    • lslezak
      over 8 years ago by lslezak | Reply

      The GitHub Pull Request Builder plugin has a nice solution for this.

      By default building PRs is disabled, you can configure it to

      • allow all repository members to run PR builds automatically
      • whitelist specific users
      • or use PR comments - the plugin watches the PR comments and if any user with push permissions writes comment "test this please" the plugin starts the build.

      See the plugin page for more details, there are some more "commands" supported.

      The workflow for the contributions coming from outside is to do a review of the PR and if it is OK (no malicious code found) write the "test this please" comment to trigger the build. The contributions from the team should be allowed to build automatically to make it easier.

      If your project does not receive a dozen of PRs a day this approach should work well. For too many PRs it would be probably better to setup building in a protected VM (no network, reset VM after every build, etc..) and build all PRs unconditionaly...

    • lslezak
      about 6 years ago by lslezak | Reply

      Update: we actually still use Travis as it now allows using Docker images, we can run an openSUSE system in Travis now, that was the main reason for searching for an alternative.

    Similar Projects

    Test Results for openQA on GitHub by livdywan

    Project Description

    Jobs in openQA are us...

    Package MONAI Machine Learning Models for Medical Applications by jordimassaguerpla

    Project Description

    MONAI Deploy aims to ...

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as roo...