- Dec 20, 2020
-
-
Georges Racinet authored
This provides the `gitaly_comparison` fixture, which stores channels to both Gitaly and HGitaly servers, as well as a whole hg-git mirroring setup, thanks to the `GitLabMirrorFixture` class provided by py-heptapod. As before, the fixture is declared in `conftest.py` (with the docstring now making fully sense), but the main class if elsewhere, namely in the `comparison` module. A first comparison test is written, which already uncovers two differences that should be fixed.
-
Georges Racinet authored
The GitalyServer class is able to configure, start and shutdown a Gitaly server, using the binaries from the Gitaly installation. The gitaly_channel fixture starts a `GitalyServer`, opens a client channel to it and waits for readiness. The fixture is defined in a package-local `conftest.py`, which has drawbacks, but it the only way to share it in practice. Most of the code is in the `gitaly` submodule anyway. Finally, `test_gitaly_server` ensures that this is working. The test is skipped if there is not known Gitaly installation, thanks to the utility provided at toplevel. Neither HGitaly nor Mercurial are involved at this point.
-
Georges Racinet authored
The ultimate goal being to be able to compare HGitaly responses to Gitaly responses, this defines concepts to describe Gitaly installations and adds a discovery system. A Gitaly installation is at this point a directory with all the compiled executables and a `ruby` subdirectory for the gitaly-ruby side. The CI will run on a base image with an existing installation, which will be specified by passing the `GITALY_INSTALL_DIR` environment variable, interpreted by these tests as a strong promise, and triggering the coverage of `tests_with_gitaly` in the `run-all-tests` script. Otherwise, the tests are able to detect the common case where HGitaly is part of a HDK workspace and use the standard location for the Gitaly checkout (after minimal checking).
-