1. 15 May, 2021 2 commits
  2. 13 May, 2021 1 commit
  3. 04 Jul, 2021 8 commits
    • Georges Racinet's avatar
      doc: HGitaly specific protocol and language libraries · 3f7820ebf7e1
      Georges Racinet authored
      also adapted the Gitaly protocol upgrade procedure to
      avoid removing the HGitaly specific `proto` files.
      I don't honestly remember why this `rm` was there. Could have been
      general concern in case an upstream proto file actually has
      to disappear (not likely, we'll deal it manually if that happens)
    • Georges Racinet's avatar
      MercurialRepositoryService: minimal impl for client testing · e36cba66fb29
      Georges Racinet authored
      The goal of this implementation is to validate that this HGitaly
      specific service can be called from the Rails app, using the
      generated HGitaly Ruby library.
      The provided `GetConfigItem` method works, but its implementation
      has to be completed with:
      - error treatment
      - `STRING` type case (the only one currently listed in the protocol)
    • Georges Racinet's avatar
      Ruby library: generated for the first time · ff03b8aef234
      Georges Racinet authored
      First committed run of `generate-grpc-lib`
    • Georges Racinet's avatar
      Ruby generated lib: Gem definition · 5ecbdbbf3749
      Georges Racinet authored
      This is enough to install the generated lib locally and use
      it from the Rails application.
    • Georges Racinet's avatar
      Ruby library: adapted generating script · 438b0a4c7693
      Georges Racinet authored
      Our files layout differs from upstream's, because of the `hgitaly`
      package name, and also because we only care about the generated lib,
      whereas Gitaly also has Ruby code of its own.
      We also derive the version module directly from `hgitaly/version`
    • Georges Racinet's avatar
      Ruby library: copy of upstream generating scripts · 40e11e7dc7ee
      Georges Racinet authored
      The `generate-proto-ruby` script and its supporting `run.rb`
      are pristine copies from Gitaly 13.12.2.
      They don't work for HGitaly at this point: this changeset is there
      to make application of upstream updates easier.
    • Georges Racinet's avatar
      Ruby generated library: initial structure · c52e3be18244
      Georges Racinet authored
    • Georges Racinet's avatar
      MercurialRepositoryService, initial definition · c2b6480dbea2
      Georges Racinet authored
      This is the first definition of Mercurial (or Heptapod)
      gRPC methods. It takes the form of a dedicated service,
      in a separate `hgitaly` protobuf package.
      ## About the separate package
      The protobufs `package` directive translates directly into a
      the module name in Ruby generated code. This doesn't happen with
      Python because Python modules and packages names are derived from
      the file system layout, wich is obviously out of control of the
      code generation.
      Upstream's Ruby generated code is packaged in a separate gem,
      historically from the `gitaly-proto` project, and soon to be
      built from the bundled proto files within Gitaly. We are not
      not going to fork either of those, and hence we need our own
      At some point, we may also need to generate a Go library,
      which require a `option go_package` statement that we couldn't
      provide right away because it means choosing the appropriate
      full path (see examples in upstream GitLab proto files).
      A consequence of using our own protobuf package for the declaration
      itself is that we need to reference the Gitaly types with their
      fully qualified name (`.gitaly.SomeType` in absolute form). Same applies
      to the options.
      - https://developers.google.com/protocol-buffers/docs/proto3#packages
      - https://developers.google.com/protocol-buffers/docs/proto#customoptions
        Quote: "Note that if you want to use a custom option in a package other
        than the one in which it was defined, you must prefix the option name
        with the package name, just as you would for type names." (example
      ## About MercurialRepositoryService itself
      This service is for Mercurial specific methods
      that are considered to be global with respect to a given
      It should cover the needs of #60 and #62
      This follows the general Gitaly style: each method gets its own pair
      of request/response messages, even if that looks to be redundant.
      The main advantage should be to give unlimited room for future change
      that would introduce actual changes.
      Reference: https://gitlab.com/gitlab-org/gitaly/blob/master/proto/README.md#design-decisions
  4. 05 Jul, 2021 3 commits
  5. 31 May, 2021 2 commits
    • Georges Racinet's avatar
      CommitService logging all incoming requests · dcef6bbdc59a
      Georges Racinet authored
      In some cases this replaces existing logs with the more complete
      dump of the request.
      Again, it's not useful to put the name of the method in the message:
      the name of the request class fulfills that purpose easily.
    • Georges Racinet's avatar
      RefService logging all incoming requests · 06e62bed644b
      Georges Racinet authored
      We don't need to include the method name in the log message,
      because of the Gitaly protocol conventions: each method has
      its own, dedicated Request class, whose name is already part of
      the rendering.
  6. 01 Jul, 2021 2 commits
  7. 21 Mar, 2021 2 commits
  8. 20 Mar, 2021 1 commit
  9. 17 Jun, 2021 5 commits
  10. 16 Jun, 2021 1 commit
  11. 26 May, 2021 5 commits
  12. 25 Mar, 2021 2 commits
  13. 23 Mar, 2021 1 commit
  14. 25 May, 2021 1 commit
  15. 04 Apr, 2021 1 commit
    • Georges Racinet's avatar
      message: wrapper class for easy logging · 10be0d6ac733
      Georges Racinet authored
      With gRPC, the `repr` of messages, notably Gitaly Requests
      is made of multiple lines.
      This is very bad for logging: a log should always be made of
      a single line for:
      - meaningful grepping
      - detangling when several processes log to the same file
      We want in particular service method to be able to log
      easily their incoming requests and/or more messages, but
      we want the formatting to be done only if the log is
      actually to be emitted (important to avoid debug logs to
      make production servers choke). This is usually achieved with
      the following pattern, because logging evaluation is inherently
      logging.debug('the interesting object is %r', obj)
      We could use extras, as `hg-loggingmod` does for the repository,
      but that is evaluated in the final formatting of the entire log
      line, and requires to register a specific format, then a specific
      handler to use it.
      The provided solution (wrapping in a class), is not zero-cost,
      but is expected to be cheap enough for the time being.
  16. 18 May, 2021 1 commit
  17. 25 Apr, 2021 2 commits