inotify is not available in docker containers, so disable this for now
as it will always cause codepaths relying on it to time out
Differential Revision: https://phab.enlightenment.org/D6601
Summary:
travis docs explicitly state that the expectation for builds is to have
2 cpus, meaning that 10 jobs is wayyyy too many and was actually causing
some build failures due to strain on the virtual hw
this sets the number of jobs using a global variable to avoid having to set
it separately for each build
https://docs.travis-ci.com/user/reference/overview/#Virtualization-environments
Reviewers: devilhorns, ManMower
Reviewed By: ManMower
Subscribers: ManMower, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6558
We want to make sure to have a stable and reliable subset of builds that
define if the build passed or not.
We also want to have builds which are more experimental. They give us a
good insight, but we are not yet ready to have them supported officially
as need-to-pass build. Namely the macOS build.
Another side effect of this change is that we reduce the critical build
matrix to 5 builds. The exact number of parallel ones we are allowed. With
fast_finish Travis will not wait for the other ones to finish before
setting the build status. This will allow us to have all builds in
parallel and not waiting for build #6 to be finished.
This has been used by myself in a branch for a while now and it is time
to bring it into master as a base for all future CI related work.
I plan to use the same scripts and other bits for Jenkins as well as
other CI systems later on.
What we currently cover with this setup are linux builds for three
different distros and MacOSX builds for two different versions.
Travis will only be called when new commits get mirrored onto our GitHub
mirror (which only happens once an hour). Expect delays on these builds.
https://travis-ci.org/Enlightenment/efl
Mike Blumenkrantz
Stefan Schmidt
Stefan Schmidt