- Jun 16, 2020
-
-
Georges Racinet authored
Up to now, we didn't declare any requirement in setup.py. We're adopting here a three-layered structure, with the full blown `dev-requirements.txt` carrying the needed tools to recompile the gRPC stubs. grpcio and grpcio-tools can be heavy to install, especially in CI context. We still have the problem that heptapod will pull Mercurial, just hoping it wouldn't mask the stable and default Mercurial versions.
-
Georges Racinet authored
The command can be launched as `hg hgitaly-serve`. Being actually a Mercurial command means it has its help page, generated from the docstring and command-line options declaration. We've made some effort to support Python 2 in the command, but currently the actual servicer code is Python 3 only, because of type annotations.
-
- Jan 09, 2020
-
-
Georges Racinet authored
We use the `pytest-grpc` helpers. This implements only the `FindCommit` RPC call, but in a complete manner. This raises several questions: - for now, we have a single `servicer` module, but Gitaly has many services: How shall we organize our code? - the fixtures for gRPC server have the module scope. Shall we have such a fixture for each service? - will we be able to create commits directly with the Gitaly API in the future? - do we want to separate the tests in several layers, ie those that don't need a gRPC server (unit-testing the `changectx_to` functions) and those that do?
-
Georges Racinet authored
commit.proto uses in turn `shared.proto` Actutally had to change the imports between these modules to the explicit relative style. That will have to be improved. Also should commit a Makefile to do this for all protos. The generated Python code should not go anywhere near a linter
-
Georges Racinet authored
Passing the `username` with `ui.config` just does not work because of the cascade of defaulting in context instantiation. It's simpler to just make a new kwarg out of it, and one more occasion to make life simpler by accepting plain `str`. Name for the `user` kwarg is in accordance with the method on the resulting changectx. The `utc_timestamp` is named to be very specific. In tests we should not need to worry with anything more complicated. This would probably not be acceptable for a general purpose library.
-
Georges Racinet authored
The versions of gitaly-proto and the gitaly server used in GitLab are not the same. In Heptapod 0.8 (based on GitLab 10.5.8), we have GITALY_VERSION=0.81.0 In turn, in gitaly 0.81.0, gitaly-proto is vendored at vendor/gitlab.com/gitlab-org/gitaly-proto, where we can see that go/VERSION is 0.84.0
-
- Jun 16, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
As done previously for py-heptapod, the latency of a separate lint stage is not justified. However lint+tests on a precompiled Mercurial version is much faster, and that justifies to push the 'stable' and 'default' Mercurial versions to a `compat` stage.
-
Georges Racinet authored
Using the ci-py-heptapod image is a simple choice to run tests with the currently supported Mercurial version, obviously the same as with py-heptapod. pytest and pytest-cov are now provided by all the base images. Doing the same initialisation for hg stable and hg default versions as in py-heptapod.
-
Georges Racinet authored
Even though that feels somewhat redundant, it's less awkward than having a hgitaly package next to a hgext3rd.gitaly one.
-
- Jan 09, 2020
-
-
Georges Racinet authored
We're running tests against latest released Mercurial versions and the heads of the stable and default branches.
-
Georges Racinet authored
We reach back 100% coverage of the testhelpers module itself.
-
- Jan 08, 2020
-
-
Georges Racinet authored
Extracted from the `py-heptapod` project and converted to Python3. These should be on PyPI, really (naming suggestions welcome). These helpers circumvent some of the bytes/string awkwardiness in Mercurial, up to a point: once we get a native Mercurial object, it's natural that for instance its description is bytes. That doesn't mean we have to pass config section names as bytes, though (but one could).
-
Georges Racinet authored
we will have a `gitaly` Mercurial extension, but that should be just a thin registration layer for our command. Most of the code will be in the `hgitaly` package, for maximum flexibility and future proofing in case we really to evade from the extension thing.
-
Georges Racinet authored
-