Skip to content
Snippets Groups Projects
  1. Mar 22, 2023
    • Georges Racinet's avatar
      Missing repository argument: proper error codes. · 9d403f00
      Georges Racinet authored
      As it was uncovered by experimental implementation in RHGitaly of
      `RepositoryExists`, it's possible that the `repository` argument
      is entirely missing. In that case, we are now raising `ValueError`
      internally, and convert it to the gRPC code
      `HGitalyServicer.STATUS_CODE_STORAGE_NOT_FOUND`.
      9d403f00
    • Georges Racinet's avatar
      servicer.load_repo: completed error treatment. · 215369c1
      Georges Racinet authored
      Up to know, we were thinking that raising `KeyError` and setting
      code and details on the context was enough, but apparently, it
      is at least problematic with streaming gRPC methods.
      
      We're instead using the two-layer organisation that was suggested
      as comment in `service.repository`. As it turns out, the error
      code to set in case of unknown storage depends at least on the
      service. This was already visible in the error treatment of the
      full path methods of `RepositoryService`, which does not need
      to be specific any more.
      
      The new `STATUS_CODE_*`class attributes make it easy to tweak the
      error code in service implementations. Specific methods could override
      them with instance attributes if needed.
      
      In the process, we're basically giving up on providing the same
      `details` as Gitaly: these are highly dependent on implementation
      (it's just stderr if the implementation relies on a
      `git` subprocess) and chances that it may matter are low, given
      that GitLab these days pushes towards "structured errors", i.e. with
      programmatically usable details provided in metadata.
      As a result, the normalization of error details in `assert_compare_errors`
      is not used any more. We're keeping it in the code base, as it may
      turn useful for forthcoming tests were the details would not be a
      simple stderr echo.
      215369c1
  2. Mar 15, 2023
  3. Mar 13, 2023
  4. Mar 12, 2023
  5. Mar 10, 2023
  6. Mar 08, 2023
  7. Feb 20, 2023
    • Georges Racinet's avatar
      Moving interceptors to hgitaly.service · 826957b9
      Georges Racinet authored
      The end goal is to allow configuring logging in one shot, both for
      sporadic logs from service methods and the systematic request logging
      done in interceptors. Such loags require to tie a format string
      using `correlation_id` to the relevant loggers, and can now be done
      for the `hgitaly.service` only.
      
      Of course it is lacking in consistency, as interceptors are not
      services. Hence the docstring proposing to introduce an intermediate
      subpackage. That would be a chore for another day, though.
      826957b9
    • Georges Racinet's avatar
      Sytematic requests logging bumped to INFO · 86ad9098
      Georges Racinet authored
      This will now be our primary source of informatiopn, with
      the supported `correlation_id`, provided the format string uses is.
      
      Converserly, logging the loading operation on repos themselves is
      generally speaking redundant, being useful only to investigate problems
      before the start of a request and the related load, hence we demote it
      to `DEBUG`
      86ad9098
    • Georges Racinet's avatar
      hgitaly.service: logging correlation_id systematically. · f70b3c51
      Georges Racinet authored
      More generally, we make use of the logger adapter that leverages
      information from the gRPC context in the whole `hgitaly.service`
      package, and we won't from other packages.
      
      The intention and the constraints that lead to it are explained
      in the new REAdME section.
      f70b3c51
    • Georges Racinet's avatar
      hgitaly.logging: new module to log correlation_id · 1d29e1b9
      Georges Racinet authored
      This provide san adapter to extract `correlation_id` from
      the gRPC context and add it to the logging `extra`, so
      that it may be used in a format, e.g.:
      `[%(asctime)s] [%(correlation_id)s] [%(levelname)s] [%(name)s] %(message)s`
      
      with the drawback that all loggers using this format will have to use
      the adapter.
      
      Minimal usage is added (`RequestLoggerInterceptor`) and support in
      `Service` fixture to get coverage with actual `ServicerContext` objects.
      
      Closes #122
      1d29e1b9
    • Georges Racinet's avatar
      c5a8ff21
    • Georges Racinet's avatar
      Logs: remove redundant · 6944f894
      Georges Racinet authored
      These were remnant of times when we didn't have the systematic
      request logging interceptor.
      6944f894
  8. Feb 17, 2023
  9. Feb 16, 2023
    • Georges Racinet's avatar
      RefService.FindLocalBranches: implement new response · f4426e4f
      Georges Racinet authored
      This new response style appears with GitLab 15.4, gated by a
      feature flag.
      f4426e4f
    • Georges Racinet's avatar
      Gitaly protocol: bump to v15.4.0 · 3635d366
      Georges Racinet authored
      3635d366
    • Georges Racinet's avatar
      RefService.FindTag: implement structured error with feature flag · 53211d8c
      Georges Racinet authored
      This is the only missing structured error implementation found by a
      full run of Gitaly Comparison tests against Gitaly v15.3.0 with all
      feature flags activated.
      
      Note: a wrong feature flag was previously set in `test_ref`, and
      was subsequently ignored, leading to the duplicated assertion passing
      (the kind expected to fail in TDD).
      Actually that was a forgotten amend before validation of !134.
      53211d8c
    • Georges Racinet's avatar
      errors.structured_abort: initial implementation · 776dea56
      Georges Racinet authored
      This the equivalent of Gitaly's `ErrWithDetails`, providing
      the capability to add "structured error details" as trailing
      metadata.
      
      Closes #108
      776dea56
    • Georges Racinet's avatar
      Feature flags: test helpers and impl for upstream v15.3 flags · a8ad8af7
      Georges Racinet authored
      In a single commit to avoid coverage headaches. Might split with
      pragmas though.
      a8ad8af7
    • Georges Racinet's avatar
      Feature flags: tests helpers · f4b9a029
      Georges Racinet authored
      Both in regular service tests and Gitaly Comparison tests,
      a mutable `feature_flags` list attribute is introduced on the
      fixture, which then takes care of sending them.
      
      (change in `test_ref.py` just to keep coverage, even though there
      is currently no actual test using this)
      f4b9a029
    • Georges Racinet's avatar
      Feature flags subsystem · 7a68a756
      Georges Racinet authored
      The first usage will be `gitaly-simplify-find-local-branches-response`,
      which is needed for GitLab 15.4 (with update of protocol).
      
      For now the definition and default values are harcoded, but we
      will probably later on synchronize them from YaML files from
      the Rails application (ideally with code generation to avoid
      dependency and parsing at the time of startup).
      
      We provide full coverage in unit tests right away, so that it
      will keep on being covered even when no feature flag is in use.
      
      Closes #121
      7a68a756
    • Georges Racinet's avatar
      testing: more robust fake contexts · 23b7ef2c
      Georges Racinet authored
      This will force us to assess the appearance of any new method
      of `grpc.ServicerContext`, hence avoiding some cases where our unit
      tests might become tautological and useless.
      23b7ef2c
  10. Feb 13, 2023
  11. Feb 12, 2023
    • Georges Racinet's avatar
      MercurialRepositoryService: implement SetManagedConfig · 7e2ac6f7
      Georges Racinet authored
      The implemenation for `inherit` field is actually
      the first time we actually make use of the
      `gl_project_full_path` field of the `Repository` message,
      perhaps even with Gitaly, as the comments in protocol definition
      hint (`SetProjectFullPath` counts as debugging).
      
      The appending logic for the main HGRC found its limit in tests,
      since the consequence is that the group inclusion occurs *after*
      the managed HGRC file inclusion, we should perhaps absorb that with
      implementation of `GetManagedConfig`.
      7e2ac6f7
  12. Feb 11, 2023
  13. Feb 12, 2023
    • Georges Racinet's avatar
      mercurial-repository.proto: undusting Mercurial config methods · 4f405afe
      Georges Racinet authored
      In the the read operation `GetManagedConfig`, with `local=true`, it
      is useful for the caller to know the difference between the setting
      being set with the a value that coincides with the current default and
      not set. In the latter case, a group setting or a global HGRC setting
      can change it.
      
      Moreover for the write operation: we don't want to accidentally override
      the absence of setting by copying over a current default to the
      project-specific managed file. We also need a way to clear settings,
      if the caller want the inherited or default value to apply.
      
      Finally, to reimplement everything that the Rails app is currently
      doing, we needed the `by_line` field.
      4f405afe
Loading