Caching the `./external` directory means that any changes to
`external/Makefile` or any updates of the submodules in `./external/*`
would not be picked up and travis would run with old instances of those,
possibly "activating" such changes after weeks or months when the cache
is pruned eventually.
Changelog-None
This is the counterpart of the annotations we did in the last few commits. It
extracts queries, passes them through a driver-specific query rewriter and
dumps them into a driver-specific query-list, along with some metadata to
facilitate processing later on. The generated query list is then registered as
a `db_config` and will be loaded by the driver upon instantiation.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
I don't remember ever seeing a bug which only showed up in VALGRIND=1 with developer
mode disabled, so don't test that, and spread out the other test more evenly.
In addition, disable the worst-performing tests in DEVELOPER=0 mode.
Here timings from my build machine: the worst 6 (- DEVELOPER=0 VALGRIND=0)
with the same tests (+ DEVELOPER=1 VALGRIND=1)
-452.42s call tests/test_pay.py::test_channel_spendable
+87.69s call tests/test_pay.py::test_channel_spendable
-335.66s call tests/test_gossip.py::test_gossip_store_compact_on_load
+47.41s call tests/test_gossip.py::test_gossip_store_compact_on_load
-332.07s call tests/test_connection.py::test_opening_tiny_channel
+89.71s call tests/test_connection.py::test_opening_tiny_channel
-331.97s call tests/test_pay.py::test_channel_spendable_large
+56.23s call tests/test_pay.py::test_channel_spendable_large
-305.28s call tests/test_invoices.py::test_invoice_routeboost
+37.57s call tests/test_invoices.py::test_invoice_routeboost
-284.28s call tests/test_plugin.py::test_htlc_accepted_hook_forward_restart
+49.12s call tests/test_plugin.py::test_htlc_accepted_hook_forward_restart
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we'll start enforcing no "maybe uninitialized" warnings at
-O3, since xenial was using gcc 5.4 or gcc 4.8 which are too primitive.
Seems like `sudo: false` is deprecated (those deps weren't being
installed); you simply install in the `before_install` hook.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our "-O3" CI check wasn't doing what I thought. But building with -flto
is hard with older gccs, so remove that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Unfortuntely we get spurious uninitialized variable warnings with
anything but -O3 or no optimization, so set default CWARNFLAGS
appropriately.
MCP bench results without optimization:
store_load_msec:28509-31001(29206.6+/-9.4e+02)
vsz_kb:580004-580016(580006+/-4.8)
store_rewrite_sec:11.640000-12.730000(11.908+/-0.41)
listnodes_sec:1.790000-1.880000(1.83+/-0.032)
listchannels_sec:21.180000-21.950000(21.476+/-0.27)
routing_sec:2.210000-11.160000(7.126+/-3.1)
peer_write_all_sec:36.270000-41.200000(38.168+/-1.9)
MCP bench with -Og: 22% speedup vs no optimization
store_load_msec:21963-23645(22841+/-6.6e+02)
vsz_kb:579916
store_rewrite_sec:10.080000-10.960000(10.456+/-0.3)
listnodes_sec:1.280000-1.390000(1.338+/-0.047)
listchannels_sec:14.770000-16.080000(15.518+/-0.46)
routing_sec:0.990000-6.660000(3.958+/-2.2)
peer_write_all_sec:29.950000-32.950000(31.138+/-1)
MCP bench with -O2: 31% speedup vs no optimization
store_load_msec:20713-22088(21505.6+/-4.8e+02)
vsz_kb:579928
store_rewrite_sec:9.570000-11.200000(10.192+/-0.54)
listnodes_sec:0.960000-1.090000(1.028+/-0.045)
listchannels_sec:10.400000-11.770000(11.012+/-0.48)
routing_sec:0.300000-3.140000(1.978+/-1.1)
peer_write_all_sec:28.980000-30.310000(29.572+/-0.44)
MCP bench with -O3 -flto: 36% speedup vs no optimization
store_load_msec:19616-20191(19862.6+/-1.9e+02)
vsz_kb:578452
store_rewrite_sec:8.980000-9.960000(9.55+/-0.32)
listnodes_sec:0.920000-1.910000(1.18+/-0.38)
listchannels_sec:8.960000-9.450000(9.206+/-0.16)
routing_sec:0.730000-1.850000(1.438+/-0.42)
peer_write_all_sec:28.090000-29.410000(28.772+/-0.42)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In one case we can reduce, in the others we eliminated if VALGRIND.
Here are the ten slowest tests on my laptop:
469.75s call tests/test_closing.py::test_closing_torture
243.61s call tests/test_closing.py::test_onchain_multihtlc_our_unilateral
222.73s call tests/test_closing.py::test_onchain_multihtlc_their_unilateral
217.80s call tests/test_closing.py::test_closing_different_fees
146.14s call tests/test_connection.py::test_dataloss_protection
138.93s call tests/test_connection.py::test_restart_many_payments
129.66s call tests/test_gossip.py::test_gossip_persistence
128.73s call tests/test_connection.py::test_no_fee_estimate
122.46s call tests/test_misc.py::test_htlc_send_timeout
118.79s call tests/test_closing.py::test_onchain_dust_out
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
Vasil Dimov
Christian Decker
arowser
Rusty Russell
fanquake
practicalswift
ZmnSCPxj