If the machine coordinating the test runs does not have jq, then test #175 fails with:
> test #1 "weave_on test-0.lon1.weave-net report | jq -r '.Router.Targets[] | tostring' | sort" failed:
> expected "test-1.lon1.weave-net
> test-2.lon1.weave-net"
> got nothing
This change completely removes the dependency on jq to make the test more robust and avoid potential confusion.
Test hard-codes a string containing '\n' and then expects echo
to interpret it as a newline, which it does not without the -e option.
This fixes flaky test runs like the below:
>>> Running /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh on [138.68.153.213 138.68.149.186]
>>> Test /root/src/github.com/weaveworks/weave/test/150_connect_forget_2_test.sh finished after 12.4 secs with error: exit status 1
test #5 "direct_peers 138.68.149.186 | sort" failed:
expected "138.68.153.213\n138.68.149.186"
got "138.68.149.186\n138.68.153.213"
Enabled hairpin mode on vethwe-bridge was one of the root causes
for installing looping flows in the fastdp mode.
Also, it confused the weave custom L2 bridge, as the bridge treats
a bounced back packet, e.g. ARP brodcast request, as a local one
(the case for "Captured a packet associated with remote host").
Previous fix in b4a43f1b85 did not work
when built with code coverage.
Running a test script with -v causes `weave_on` to output progress
messages, so we don't want to use those commands inside `$()`
test #4 "[
3e52b548e6df304c61ea5bee0af4b3515e025e7e25152c65ecae3d03c71cf52d ==
Unable to claim: address 10.32.0.3/12 is already owned by
fbe411facc8b657c5850591ab56fc40fb56160d43db0d7363a29ba3edad61134
Unable to claim: address 10.32.0.1/12 is already owned by
cf16a2bcdee8dd1ef7e5f0a611127611e67ea734f45d7526678fc3b1fc0c6f5d
3e52b548e6df304c61ea5bee0af4b3515e025e7e25152c65ecae3d03c71cf52d ]"
failed:
program terminated with code 2 instead of 0
1 of 6 tests failed in 6.499s.
The smoke-tests are meant to be run in a context where you have just
uploaded a build. If that upload failed and we don't do this check
then we will download the 'latest' images from DockerHub.
Bryan Boreham