- Nov 15, 2020
-
-
Georges Racinet authored
Same as done yesterday with py-heptapod, we can't make it a blocker that the tests pass against the current head of the Mercurial default branch.
-
- Oct 16, 2020
-
-
Georges Racinet authored
This raises the question of homegeneity of branch naming conventions between py-heptapod and HGitaly (see long comment, with reference to heptapod#352) There was also a glitch while installing py-heptapod. The solution adopted is a path of least resistance.
-
- Jul 30, 2020
-
-
Georges Racinet authored
I can't remember why it's not been done in aaea40d0ae4a, and there's no note about that: it must have been a mistake. We currently have some unrelated failures in the 'stable' build due to Mercurial stable be apparently 5.5 now
-
- Jun 17, 2020
-
-
Georges Racinet authored
A side benefit of `--doctest-modules` is that it will import all Python modules (looking for doctests in them), and by doing so, it will find missing `__init__.py` files and other inconsistent imports.
-
Georges Racinet authored
It's becoming pretty clear that we'll have a fair amount of code to share between HGitaly and py-heptapod, for instance anything that involves GitLab branch conventions. In that context, developping HGitaly against released versions of py-heptapod would strongly undermine our velocity, at least for a while. The py-heptapod repo is small enough that a full clone from foss.h.n is not a problem (and Heptapod Workhorse is on our side these days). We could later on preclone in the base Docker image, though.
-
- Jun 16, 2020
-
-
Georges Racinet authored
Hoping it'll give us the very fast build we yearn for.
-
Georges Racinet authored
Same as in most other CI configurations: failing on the head of Mercurial default branch should not be a blocker.
-
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?
-
- Jun 16, 2020
-
-
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.
-
- Jan 09, 2020
-
-
Georges Racinet authored
We're running tests against latest released Mercurial versions and the heads of the stable and default branches.
-