- 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.
-
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
-