Skip to content
Snippets Groups Projects
  1. Aug 04, 2021
  2. Aug 03, 2021
  3. Jul 19, 2021
  4. May 28, 2021
  5. May 31, 2021
  6. May 15, 2021
  7. May 13, 2021
  8. 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
  9. Jul 05, 2021
  10. 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
  11. Jul 01, 2021
  12. Mar 21, 2021
  13. Mar 20, 2021
  14. Jun 17, 2021
  15. Jun 16, 2021
  16. Jun 11, 2021
  17. May 26, 2021
Loading