Some tests shall be run against our own SSH server we spin up in Travis.
As those need to be run separate from our previous tests which run
against git-daemon, we have to do this in a separate step. Instead of
bundling all that knowledge in the CI script, move it into the test
build instructions by creating a new test target.
Right now, we test our credential callback code twice, once via SSH on
localhost and once via a non-existent GitHub repository. While the first
URL makes sense to be configurable, it does not make sense to hard-code
the non-existing repository, which requires us to call tests multiple
times. Instead, we can just inline the URL into another set of tests.
We support two types of passing credentials to the proxy, either via the
URL or explicitly by specifying user and password. We test these types
by modifying the proxy URL and executing the tests twice, which is
in fact unnecessary and requires us to maintain the list of environment
variables and test executions across multiple CI infrastructures.
To fix the situation, we can just always pass the host, port, user and
password to the tests. The tests can then assemble the complete URL
either with or without included credentials, allowing us to test both
cases in-process.
Some tests of ours require to be running against an SSH server.
Currently, we simply run against the SSH server provided and started by
Travis itself. As our Linux tests run in a sudo-less environment, we
have no control over its configuration and startup/shutdown procedure.
While this has been no problem until now, it will become a problem as
soon as we migrate over to newer Precise images, as the SSH server does
not have any host keys set up. Luckily, we can simply set up our own
unpriviledged SSH server. This has the benefit of us being able to
modify its configuration even in a sudo-less environment.
This commit sets up the unpriviledged SSH server on port 2222.
It takes a bit for the propxy to get ready to accept connections, so
start it before the build so we can be reasonably sure that it's going
to be ready in time.
We were missing this test on Windows, which meant we didn't notice that
we never fixed the single authentication attempt it tries, nor its wrong
return code.
Enable this for the unix platforms as well over HTTP. We previously were
doing it locally but disabled it on OS X due to issues with its sshd not
accepting password authentication.
These tests were not being taken into consideration for the failure of
the test. They've been failing for a while now, but we hadn't noticed as
Travis was reporting the builds successful.
git allows you to set which paths to use for the git server programs
when connecting over ssh; and we want to provide something similar.
We do this by providing a factory function which can be set as the
remote's transport callback which will set the given paths upon
creation.
Our ssh tests assume that the server supports password authentication
in a few places. This is convenient as we're not testing authentication
methods, but what happens around them.
Tell sshd on OSX to accept this form of authentication.
An empty string is not a valid number, and some shells complain.
Check instead if $COVERITY is non-empty, which is a common convention
and what we're doing anyway.
When implementing the ssh testing, the move to the script made it so
the first test suite's exit code was ignored. Check whether the main
tests fail and exit with an error in that case.
Set up the ssh credentials so we are able to talk to localhost and
issue git commands. Move to use a script, as the command list is
getting somewhat long.
While here, delay installing valgrind until we need it, as it and its
dependencies are by far the largest downloads and this allows us to
start compiling (and failing) faster and we only incur this cost when
the test suite runs successfully.
