Skip to content
Snippets Groups Projects
  1. Aug 24, 2021
  2. Aug 23, 2021
    • Georges Racinet's avatar
      Next version will be 0.15 · ad9dbe8dcd2d
      Georges Racinet authored
      We have a bump of protocol, even if it looks to be orthogonal
      to Mercurial concerns
      ad9dbe8dcd2d
    • Georges Racinet's avatar
      Bumped upstream Gitaly protocol to 14.0.0 · 53a2b9627c97
      Georges Racinet authored
      Notable differences:
      
      - The Golang library package path now based on the major
        version number (`/v14')
      - RPC methods for remote mirror updating (should be only
        in the push direction).
      - Removal of some Wiki methods.
      53a2b9627c97
  3. Aug 04, 2021
  4. Aug 03, 2021
  5. Jul 19, 2021
  6. May 28, 2021
  7. May 31, 2021
  8. May 15, 2021
  9. May 13, 2021
  10. Jul 04, 2021
    • 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)
      3f7820ebf7e1
    • 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)
      e36cba66fb29
    • Georges Racinet's avatar
      Ruby library: generated for the first time · ff03b8aef234
      Georges Racinet authored
      First committed run of `generate-grpc-lib`
      ff03b8aef234
    • 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.
      5ecbdbbf3749
    • 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`
      438b0a4c7693
    • 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.
      40e11e7dc7ee
    • Georges Racinet's avatar
      Ruby generated library: initial structure · c52e3be18244
      Georges Racinet authored
      c52e3be18244
    • 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
      package.
      
      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.
      
      References:
      
      - 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
        follows)
      
      ## About MercurialRepositoryService itself
      
      This service is for Mercurial specific methods
      that are considered to be global with respect to a given
      repository.
      
      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
      c2b6480dbea2
  11. Jul 05, 2021
  12. May 31, 2021
    • 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.
      dcef6bbdc59a
    • 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.
      06e62bed644b
  13. Jul 01, 2021
  14. Mar 21, 2021
  15. Mar 20, 2021
  16. Jun 17, 2021
Loading