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).
Here is what happens when you push a change to e.org/efl.git:
Depending on the available Travis resources such a build takes 20-30 minutes (macOS is the bottleneck).
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:
Depending on the available Travis resources such a build can take up to 60 minutes
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.
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.
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).
We use ccache in our builds and cache the results in the Travis caching directories to save build time.
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.
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.
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.