Skip to content
Snippets Groups Projects
  1. Jan 11, 2021
  2. Jun 19, 2020
    • Georges Racinet's avatar
      Support multiple storages · 5cca85c5
      Georges Racinet authored
      This was left aside in the project bootstrap.
      We won't actually need multiple storages for a while, hence
      the server command still uses a single `repositories-root`.
      
      But we better have the internals support multiple storages right
      away: its easier to do right now than to add it afterwards.
      5cca85c5
  3. Jun 17, 2020
    • Georges Racinet's avatar
      default branch: setting method, in RepositoryService · 78967998
      Georges Racinet authored
      In current GitLab, setting the default branch from the
      Rails app is done by the `Project` model, which
      in turn does:
      
        repository.raw_repository.write_ref('HEAD', "refs/heads/#{branch}")
      
      and write_ref is provided by RepositoryService
      78967998
  4. Jun 16, 2020
    • Georges Racinet's avatar
      default branch: getting method, in RefService · 8f37591c
      Georges Racinet authored
      this is where reading the default branch is implemented.
      8f37591c
    • Georges Racinet's avatar
      Split CommitServicer in its own module. · 1da2c879
      Georges Racinet authored
      Keeping what's expected to be shared by all HGitaly services in
      the `HGitalyServicer` mixin class.
      1da2c879
    • Georges Racinet's avatar
      tests: preparation to test several services · 15321a68
      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.
      15321a68
  5. 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
Loading