Currently valgrind developer tests are taking about 25 minutes,
with the non-developer valgrind taking 32.
Split into 6 parts and 2 parts respectively.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Adds two new environment variables TEST_GROUP_COUNT and TEST_GROUP to
split the integration tests into groups and run only a selected group.
This allows us to increase the TEST_GROUP_COUNT and add a new
TEST_GROUP to avoid bumping up against the time limit when running in
valgrind.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Due to the large number of changes in phrasing, we'd have a large
number of CI builds failing. So just temporarily disable BOLT
checking.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Shows us progress while downloading images and we can verify that the
images match what we expect. `tee` is mainly used to disable the pull
animation that was spamming the logs otherwise.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is a bit messier than I'd like, but we want to clearly remove all
dev code (not just have it uncalled), so we remove fields and functions
altogether rather than stub them out. This means we put #ifdefs in callers
in some places, but at least it's explicit.
We still run tests, but only a subset, and we run with NO_VALGRIND under
Travis to avoid increasing test times too much.
See-also: #176
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Run one travis build with valgrind on legacy tests, off on new daemon
tests, and another build with the roles switched. Should also speed
this up a bit since we run in parallel.
The Dockerfile is now stored in contrib and built using the Docker
Hub. This allows us to simply pull in the finished image from the hub
instead of having to build it ourself. Should shave off about 2
minutes from the build time.
I also switched to running the individual build and check steps in
their own containers, but on the same volume, so travis can group the
commands and run them independently.
Added .travis.yml to get travis-ci to build and run tests for us.
In addition this fixes a flaky test due to the fact that when lightning2
connects to lightning3 and we tell lightning3 to restart, then
lightning2 will back-off its reconnection attempts, potentially causing
a timeout to trigger during tests. This was triggered by travis-ci
relatively consistently since the restart would take quite some
time. Now simply restarting them in reverse order and a small timeout
seems to fix this consistently.
Rusty Russell
practicalswift
ZmnSCPxj
Christian Decker