Also reduce number of people in conference to 5, because on Circle CI the
test times out trying to connect more than 6 or 7 people. The persistent
conferences PR will improve this so we can set it much higher then.
Since trusty has more up-to-date packages, we can remove some of the
custom install code. Also, we're not using hstox at the moment, so there
is no need to slow down the builds for now.
Still run all the jobs during cron and regular push to branch. We
disabled build for push to branch, so cron is the only place where all
builds are run. This also means we need to worry less about spending time
in nightly builds, because they occur only once a day.
See https://github.com/travis-ci/travis-ci/issues/9071
Travis has upadted their VM image and by default the latest is being used.
This has caused our Windows builds to fail due to them exceeding Travis's log
limit of 4mb. It appears to be due to the new Docker version the new Trusty
image has, it somehow changed network behaviour in a way that makes toxcore
network module output a lot more of log messages than it used to.
Given that it fails about 80-90% of the time, it's not worth requiring
it to pass. Instead, we'll need to manually look at the osx build to see
in what way it failed.
Also, set `fast_finish` to true, since OSX regularly has multi-hour (up
to half a day) outages that can't block us for trivial code changes or
non-code changes.
Also, fix the hstox build that was taking half an hour. It now takes 5 minutes.
Also, perform distcheck on travis to ensure that make dist works. It's not
actually failing the build at the moment due to broken tests.
This is in preparation for having multiple types of build. One of the future
builds will be a hstox build, another may be frama-c or some other static
analyser. It makes sense to split these up into multiple builds, because each of
them can take a while, and running them in parallel will speed things up. Also,
the hstox test coverage should be reported separately from the toxcore auto_test
coverage.
> increased the timeout for TCP tests because per @irungentoo the network on Travis-CI can be slow sometimes
> allowed groupchats test to restart on error until timeout This had to be done because current groupchats are fundamentally broken and 3/5 times they'll 'net-split' on connect
>> Drop group chat tests, add comment to the reason
> added some debugging information to TCP tests, and a #define to force IPV6 (Travis-CI only uses IPv4 on their containers) and decreased the itr interval
> Went crazy with timeouts for Tox network stuff on Travis. Tests on TCP will still randomly fail due to timeouts. I can't reproduce on any local system. So again per @irungentoo, Travis is slow, let's offer it a short bus.
- We use coveralls.io to report on test coverage and avoid getting below a
certain threshold. The threshold is currently 60%, but we will be increasing
it when it stabilises.
- We use gcc/clang -ftest-coverage and gcov to measure C test coverage.
- We switched to container based Travis build infrastructure, which has the
advantage of faster boot times[1] (1-6s vs. 20-52s). The trusty beta supports
caching, but the longer boot times make it an unattractive target.
- We now need to build more dependencies ourselves and cache the result. We
still fetch what we can (currently opam, libvpx, and check) from apt.
[1] https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments
Reduces the running time from about 8 minutes to about 5, as it uses
packaged libraries instead of building them. This is possible because
of the Ubuntu Trusty becoming available on Travis. The new check that
is in Trusty has different behaviour than the previously user version
of it -- it doesn't output the detailed result of tests. To fix this
we cat a file where this detailed result is stored.
