Skip to content
Snippets Groups Projects
  1. Jun 16, 2020
    • 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
    • Georges Racinet's avatar
      bootsrap: generated gRPC stubs for CommitService · 7196784b
      Georges Racinet authored
      commit.proto uses in turn `shared.proto`
      
      Actutally had to change the imports between these modules to
      the explicit relative style. That will have to be improved.
      
      Also should commit a Makefile to do this for all protos.
      
      The generated Python code should not go anywhere near a linter
      7196784b
    • Georges Racinet's avatar
      testhelpers: commit user and date · 51198415
      Georges Racinet authored
      Passing the `username` with `ui.config` just does not
      work because of the cascade of defaulting in context instantiation.
      It's simpler to just make a new kwarg out of it, and one more
      occasion to make life simpler by accepting plain `str`.
      Name for the `user` kwarg is in accordance with the method on the
      resulting changectx.
      
      The `utc_timestamp` is named to be very specific. In tests we should
      not need to worry with anything more complicated. This would probably
      not be acceptable for a general purpose library.
      51198415
    • Georges Racinet's avatar
      Imported protobuf specs from gitaly-proto 0.84 · 37a9215d
      Georges Racinet authored
      The versions of gitaly-proto and the gitaly server used in
      GitLab are not the same.
      
      In Heptapod 0.8 (based on GitLab 10.5.8), we have
      GITALY_VERSION=0.81.0
      
      In turn, in gitaly 0.81.0, gitaly-proto is vendored
      at vendor/gitlab.com/gitlab-org/gitaly-proto, where we can
      see that go/VERSION is 0.84.0
      37a9215d
  3. Jun 16, 2020
  4. Jan 09, 2020
  5. Jan 08, 2020
    • Georges Racinet's avatar
      Test helpers · cba4d9f1
      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).
      cba4d9f1
    • Georges Racinet's avatar
      General project structure · e890e844
      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.
      e890e844
    • Georges Racinet's avatar
      Classic ignore file for python project · 22b40d56
      Georges Racinet authored
      22b40d56
Loading