Skip to content
Snippets Groups Projects
  1. Jun 17, 2020
  2. Jun 16, 2020
  3. Jun 17, 2020
    • Georges Racinet's avatar
      Added license (GPLv2+) · 8738f8e1ab9f
      Georges Racinet authored
      Doing that before we accumulate more source files.
      
      It didn't feel right for the stubs: not only is this
      generated code, but also does it come from source (proto files)
      onto which we have no copyright.
      
      Same for placeholders like __init__.py for namespace packages:
      that's not really of our doing.
      8738f8e1ab9f
    • Georges Racinet's avatar
      tests: using heptapod.testhelpers · a03eb27e19a3
      Georges Racinet authored
      With py-heptapod supporting both Python 2 and 3, not so much
      was left to make HGitaly tests use its test helpers directly,
      ending this de facto fork.
      
      This is also a first use case for the CI running against
      the head of py-heptapod default branch.
      a03eb27e19a3
    • 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
  4. Jun 16, 2020
    • Georges Racinet's avatar
      Split CommitServicer in its own module. · 1da2c87983d7
      Georges Racinet authored
      Keeping what's expected to be shared by all HGitaly services in
      the `HGitalyServicer` mixin class.
      1da2c87983d7
    • Georges Racinet's avatar
      tests: preparation to test several services · 15321a685409
      Georges Racinet authored
      The `grpc_add_to_server` and `grpc_servicer` fixtures were
      just conveniences to feed the final server fixture,
      `grpc_server`, that we can redefine without so much duplication
      (most of the job is done in the definition of the lower level
      `_grpc_server`).
      
      At the other side of the spectrum, `grpc_stub_cls` was just
      a convenience to feed the actual `grpc_stub`. Again most of
      the job is just done in `grpc_channel` (that depends on
      `grpc_server` so that something is actually listening), and
      we just use `grpc_channel` and instantiate the stub to get
      a working client on our test class.
      
      In the end, we'll be able to add more servicers to `grpc_server`,
      and each test will use the appropriate stubs: tests depending
      on several services will simply use several stubs on a single
      channel.
      15321a685409
    • Georges Racinet's avatar
      default branch: compiled necessary service protos · ad25785067e5
      Georges Racinet authored
      The reading is done by `RefService` whereas the setting is
      done by `RepositoryService`, in `WriteRef`.
      ad25785067e5
    • Georges Racinet's avatar
      Regenerated stubs for Gitaly proto v12.10.6 · 6b6d97642bfc
      Georges Racinet authored
      `lint.proto` is a new dependency among them.
      
      Still the same problem with imports that have to be converted
      to relative style.
      6b6d97642bfc
    • Georges Racinet's avatar
      Updated Gitaly protocol definition to v12.10.6 · 8e66716ba3a8
      Georges Racinet authored
      The proto files are now versioned with Gitaly itself.
      Also it seems that the Gitaly server version is identical
      to the GitLab version, but we should always check.
      8e66716ba3a8
    • 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
      FindCommit: 'revision' is actually a Git revspec. · 6eddb1503729
      Georges Racinet authored
      This is a nice example of how a guess based on the type of an
      argument can be wrong.
      
      First tries with actual GitLab client showed that this revision
      is called "id_or_ref" on the client side, and can be either
      - a SHA ("id")
      - a GitLab branch name ("ref")
      - HEAD, meaning the head of the default branch,
        not supported yet in HGitaly.
      
      Just hoping there's not more advanced syntax such as `master~3`
      that would force us to do a full conversion from Git revspec to
      Mercurial revset syntax.
      6eddb1503729
    • 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
  5. 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
    • Georges Racinet's avatar
      bootsrap: generated gRPC stubs for CommitService · 7196784b950a
      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
      7196784b950a
    • Georges Racinet's avatar
      testhelpers: commit user and date · 51198415b69b
      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.
      51198415b69b
    • Georges Racinet's avatar
      Imported protobuf specs from gitaly-proto 0.84 · 37a9215d5992
      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
      37a9215d5992
  6. Jun 16, 2020
  7. Jan 09, 2020
  8. Jan 08, 2020
    • Georges Racinet's avatar
      Test helpers · cba4d9f14f24
      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).
      cba4d9f14f24
    • Georges Racinet's avatar
      General project structure · e890e844cb26
      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.
      e890e844cb26
    • Georges Racinet's avatar
      Classic ignore file for python project · 22b40d5604f9
      Georges Racinet authored
      22b40d5604f9
Loading