- Feb 09, 2021
-
-
Georges Racinet authored
with the exclusion rule, it was inconvenient to launch flake8 manually, I was always doing it by a copy-paste from the CI config file.
-
- Jan 12, 2021
-
-
Georges Racinet authored
-
- Dec 18, 2020
-
-
Georges Racinet authored
This is hooked in the "current" test, and indeed the Heptapod base image with Gitaly is supposed to have the Mercurial version for the current heptapod. The environment variable triggers coverage of the tests with Gitaly, which proves in particular that they are indeed launched.
-
- Dec 20, 2020
-
-
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).
-
- Dec 02, 2020
-
-
Georges Racinet authored
Not actually needed in the most common cases… until it is!
-
- Dec 04, 2020
-
-
Georges Racinet authored
Hence in the HGitaly stable branch, we'll run in the `mercurial/hg-current:stable` base image, while in the HGitaly default branch, it'l be on `mercurial/hg-current:default`. (the base image is ready for that)
-
Georges Racinet authored
In the stable branch of HGitaly, we are using a fixed Mercurial version, therefore it's not interesting to check for incompatibilities with future versions: merges to default will tell us about them.
-
- 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.
-