Skip to content
Snippets Groups Projects
  1. Jun 16, 2020
    • Georges Racinet's avatar
      heptapod-ci: allowing failures for Mercurial default · 808cacec
      Georges Racinet authored
      Same as in most other CI configurations: failing on
      the head of Mercurial default branch should not be a blocker.
      808cacec
    • Georges Racinet's avatar
      Declaration and organisation of Python dependencies · df655a5c
      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.
      df655a5c
    • Georges Racinet's avatar
      bootstrap: server command · 225920b2
      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.
      225920b2
  2. Jan 09, 2020
    • Georges Racinet's avatar
      bootstrap: demo CommitService servicer tested with pytest · e5a54fef
      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?
      e5a54fef
  3. Jun 16, 2020
    • Georges Racinet's avatar
      heptapod-ci: main/compat stages instead of lint/tests · e519ff2d
      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.
      e519ff2d
    • Georges Racinet's avatar
      heptapod-ci: adaptation to current base images · 49f3e466
      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.
      49f3e466
  4. Jan 09, 2020
Loading