canceled builds indicate that someone is actively watching a build,
likely in order to test changes. there's no point in spamming irc for
these events
Differential Revision: https://phab.enlightenment.org/D6730
examples and install are both built by distcheck build, no need to also
build them in every other build
there's also no need to try building an app against the compiled libraries
since ci runs unit tests, requiring binaries to run after linking to the
libraries
Differential Revision: https://phab.enlightenment.org/D6663
Summary:
if env vars change between runs then the cache is invalidated, causing
configure to print a very specific error
by running a separate script to catch this error, the build can detect
and clear the cache when necessary to avoid having to manually disable
the cache when changing build settings
Depends on D6697
Reviewers: stefan_schmidt, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6732
this will be useful while profiling CI builds to know whether a patch
has made builds slower so that it can potentially be examined
Differential Revision: https://phab.enlightenment.org/D6666
travis upgraded to macos high sierra overnight without notification(?)
and this is now required in order to find openssl for some reason
also disable config.cache to prevent configure errors
Differential Revision: https://phab.enlightenment.org/D6718
this adds a script to run make check after the build has finished,
repeating tests 3 times to try and reduce false positives from intermittent
failure tests
ref T7094
Differential Revision: https://phab.enlightenment.org/D6617
this adds the downloaded homebrew package files to a cache in order to
avoid needing to separately download each file at the start of each build
not sure we can do better here unless we buy the enterprise-level travis
package which allows building with custom osx images which we could pre-install
all these dependencies on
ref T7096
Differential Revision: https://phab.enlightenment.org/D6610
this enables caching of the autoreconf and ./configure stages of the build
using autotools-provided caching mechanisms in order to speed up these steps
fix T7136
Differential Revision: https://phab.enlightenment.org/D6608
this enables and implements full support for ccache on travis builds
fix T7126
Differential Revision: https://phab.enlightenment.org/D6605
=also includes previously-submitted patches=
ci: split out ccache config setup into separate script
this provides a more unified place to set ccache options
also enable ccache compression to cut down on cache upload/download overhead
ref D6613
ci: zero ccache stats before build and add some comments for options used
zeroing the stats before each build will provide more insight into the cache
performance for each build
ref D6621
ci: break out ccache stat printing into separate script
continue to make travis.yml more readable
ref D6622
ci: add more ccache config options to improve cache direct hits
ci: disable second cpp run for ccache
this should avoid running cpp twice for files
https://ccache.samba.org/manual.html#_the_preprocessor_mode
this moves each step of the ci build into a separate script with the build
type passed as an argument, allowing for easier modification of each individual
step as necessary and making travis.yml more readable
Differential Revision: https://phab.enlightenment.org/D6604
also includes:
ci: break out make commands into travis.yml from build scripts
this simplifies the platform-specific build scripts to only perform
the configure stage of the build (and any additional setup) and then
uses standardized commands for the build
in addition to being simpler, this will also provide more/better info
about build timings
ref D6603
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