- Jun 16, 2020
-
-
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
-