Skip to content

Bootstrapping RHGitaly

Georges Racinet requested to merge topic/default/rhgitaly-tonic into branch/default

For the general plan, see #118 (closed).

This first effort is based on the asynchronous Tonic framework (part of the Tokio ecosystem)

Features

Two requests are implemented:

  • ServerService.ServerInfo: the simplest possible
  • RepositoryServer.RepositoryExists: does not really need Mercurial logic

The server binds on TCP and Unix Domain sockets.

There is no fallback to the regular HGitaly for unimplemented methods. According to Tonic maintainers, this might not even be possible. The short term plan will be client-side dispatching (Rails application), as we'll have but a handful of methods, expected to be fairly stable for a while. Transparent dispatching would have to involve a fallbacking load balancer, perhaps even custom built.

Also we had to trim the protocol down to the methods we implement, in order not to copy over (and have to maintain) scores of stub implementations with painfully long signatures.

Developement and testing

Included is the support for RHGitaly in Gitaly Comparison tests, allowing to check both HGitaly and RHGitaly against Gitaly when needed, with a simple pytest parametrization (see example in tests_with_gitaly/test_repository.py). There is also support for direct comparison between RHGitaly and HGitaly (see tests_with_gitaly/test_server.py) when Gitaly comparison is not relevant.

The CI/CD harness has been upgraded to run the RHGitaly comparison test runs (look for test_repository_exists[rhgitaly] in the job log. Finally, we moved the Comparison tests to the compat stage, and reuse the compilation done in the new tests-rust job, thanks to artifacts. The crate downloads are kept in a CI cache.

Edited by Georges Racinet

Merge request reports