Skip to content
Snippets Groups Projects
  1. Nov 15, 2020
  2. 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
  3. Jul 30, 2020
  4. 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
  5. 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
  6. 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
  7. 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
  8. Jan 09, 2020
Loading