<p dir="ltr"><br>
On Jul 12, 2016 5:27 PM, "Jason A. Donenfeld" <<a href="mailto:zx2c4@gentoo.org">zx2c4@gentoo.org</a>> wrote:<br>
> That's a good point. Alright, that seems sufficient motivation for me<br>
> to construct a good automated test harness.</p>
<p dir="ltr">So I briefly thought about this and made some infrastructure changes. The <a href="http://demo.wireguard.io">demo.wireguard.io</a> box is now infrastructure stable enough for use in automated test suites. So, as a first run at an automated test, these things could happen:</p>
<p dir="ltr">1. dpkg -i path/to/pkgs<br>
2. Set up a wireguard tunnel to the demo box.<br>
3. ping -c 1 the demo box through the tunnel and see if it reports success.<br>
4. remove the wireguard tunnel.</p>
<p dir="ltr">If these succeed, it passes.</p>
<p dir="ltr">Now (2) is a subtle point. It's not a good idea to use the private key in the contrib/external-tests/ because it's possible somebody else will be using it. (As a general rule, private keys should never be shared or leave the box on which they were generated.) Alternatively, the ncat client.sh can be used to provision things dynamically. Or, you could generate a private key that remains private on debian infrastructure, and send me the public key. I'm okay with either.</p>
<p dir="ltr">However, it might be easiest to simply use network namespaces and run all this locally. I'm about to take an airplane; I'll create a 'make test' that does this. Then you could just incorporate calling that into your build system; would that work for you?</p>