Skip to content
Snippets Groups Projects
  1. Feb 09, 2021
    • Georges Racinet's avatar
      lint: new separate script · 6f66184bcf1c
      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.
      6f66184bcf1c
  2. Jan 12, 2021
  3. Dec 18, 2020
    • Georges Racinet's avatar
      Heptapod CI: running tests with Gitaly · e99c640a1949
      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.
      e99c640a1949
  4. Dec 20, 2020
    • Georges Racinet's avatar
      Gitaly comparison tests: discovery of Gitaly installation · 024370a05311
      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).
      024370a05311
  5. Dec 02, 2020
  6. Dec 04, 2020
  7. Nov 15, 2020
  8. Oct 16, 2020
    • Georges Racinet's avatar
      Heptapod CI: using the new base CI images · 37d21a0e709c
      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.
      37d21a0e709c
  9. Jul 30, 2020
  10. Jun 17, 2020
    • Georges Racinet's avatar
      Running doctests, with new `run-all-tests` script · 6484beef902c
      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.
      6484beef902c
    • Georges Racinet's avatar
      heptapod-ci: running on unreleased py-heptapod · 653a45ddfdaa
      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.
      653a45ddfdaa
  11. Jun 16, 2020
    • Georges Racinet's avatar
      heptapod-ci: using new dedicated images for HGitaly · aaea40d0ae4a
      Georges Racinet authored
      Hoping it'll give us the very fast build we yearn for.
      aaea40d0ae4a
    • Georges Racinet's avatar
      heptapod-ci: allowing failures for Mercurial default · 808cacecb0d2
      Georges Racinet authored
      Same as in most other CI configurations: failing on
      the head of Mercurial default branch should not be a blocker.
      808cacecb0d2
    • Georges Racinet's avatar
      Declaration and organisation of Python dependencies · df655a5c3c66
      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.
      df655a5c3c66
    • Georges Racinet's avatar
      bootstrap: server command · 225920b2ad2e
      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.
      225920b2ad2e
  12. Jan 09, 2020
    • Georges Racinet's avatar
      bootstrap: demo CommitService servicer tested with pytest · e5a54fefe3f0
      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?
      e5a54fefe3f0
  13. Jun 16, 2020
    • Georges Racinet's avatar
      heptapod-ci: main/compat stages instead of lint/tests · e519ff2d8898
      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.
      e519ff2d8898
    • Georges Racinet's avatar
      heptapod-ci: adaptation to current base images · 49f3e4669fad
      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.
      49f3e4669fad
  14. Jan 09, 2020
Loading