CI Overview

Our CI pipeline sits on Travis CI and is configured with the .travis.yml file in the root of our git repo. All other CI related build scripts and data can be found in the .ci subfolder.

To start our CI pipeline we have two different triggers. The first event that triggers a start of the CI pipeline is a git push to our git server (which gets instantly mirrored to our Github mirror and triggers Travis). The second trigger is a daily cron run directly from Travis itself at around ~ 17:30 CEST (time can vary depending on Travis load).

Git push CI Pipeline

Here is what happens when you push a change to e.org/efl.git:

• A git hook on the server will push out the new changes to our GitHub mirror instantly
• GitHub notifies Travis CI on repo changes
• Travis takes the latest change (all commits in one push, not individual commits) and starts a build
• 6 different jobs are running on each push
  • Native macOS build
  • Windows cross build with MinGW and ewpi for dependencies (this includes a native build of tooling needed for the full cross build afterwards)
  • Linux build with all options (as much as possible combined) enabled
  • Linux build with all options (as much as possible to have working build) disabled
  • Linux build with wayland options enabled (this build includes ninja install, ninja test & example application build test)
  • Linux build with default options (this build includes ninja install, ninja benchmark, ninja test & example application build test)

Depending on the available Travis resources such a build takes 20-30 minutes (macOS is the bottleneck).

Daily cron CI Pipeline

The daily cron job is running at ~ 17:30 CEST (Travis is not strict on the exact time). The cron job takes the current HEAD of master at the time the job starts. In addition to the 6 jobs we have for every build the cron jobs add 11 more to a total of 17 jobs:

• A release ready job which runs a full ninja dist
• 3 Linux distro builds (Ubuntu latest, Ubuntu LTS, Debian stable)
• Coverity Scan run and upload for analysis (a mail to e-devel will be send for newly detected issues after analysis)
• Address sanitizer enabled build
• Exactness job running tests on elementary_test scenarios (pixel perfect regression and integration test-suite)
• Codecov code coverage run (build with Travis Ubuntu Bionic distro)
• Native arm64 arch (build with Travis Ubuntu Bionic distro)
• Native ppc64le arch (build with Travis Ubuntu Bionic distro)
• Native s390x arch (build with Travis Ubuntu Bionic distro)

Depending on the available Travis resources such a build can take up to 60 minutes

CI Details

In addition to the overview above we here have some details on different parts of our systems. It should help a bit to understand the mechanics of it.

Testing

When executing our ninja test on CI we have a few extra details to make it run better on potentially overloaded CI systems. We have experienced some instability when running our tests on Travis before, not all of these might still be needed. We are increasing the test timeout to 120s from the default 30s and we are running the test-suites in a loop which would run up to five times in case the tests are failing.

Docker images

To support the various builds on Travis we have a bunch of docker images with the needed dependencies for efl pre-installed. The source for these docker images is the ci-support-files github repo where our Dockerfiles live. They will be automatically build on docker hub and pulled during a Travis run (when not already cached).

Caching

We use ccache in our builds and cache the results in the Travis caching directories to save build time.

Developer Branches

Every developer with commit access can push to their devs/$ID/ branches to trigger these builds and check the results before putting things into Phab. This has been proven useful for bigger changes without having access to all the different test environments.

Travis native vs. docker builds

For most of our builds we are using docker images. This allows better control of the image as well as running them locally for debugging and testing. Some of the features we are using on Travis are only available with their native builds (namely macOS, arm64, ppc64le and s390x builds as well as nice codecov integration). We run these jobs directly on the Travis provided images to make use of this functionality.

Travis fold and timers

In our scripts we make use of travis_fold and travis_time_* bash functions (we export them in .travis.yml) to allow us to fold particular parts of the logs neatly on the webui. The travis_time* calls allow us to log the spent time for each of these sections which gives a good overview where we spend time in our build.