- Feb 20, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
These were remnant of times when we didn't have the systematic request logging interceptor.
-
- Feb 17, 2023
-
-
Georges Racinet authored
We have a protocol update, due to the sync with Gitaly v15.4
-
- Feb 16, 2023
-
-
Georges Racinet authored
This new response style appears with GitLab 15.4, gated by a feature flag.
-
Georges Racinet authored
-
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.
-
Georges Racinet authored
This the equivalent of Gitaly's `ErrWithDetails`, providing the capability to add "structured error details" as trailing metadata. Closes #108
-
Georges Racinet authored
In a single commit to avoid coverage headaches. Might split with pragmas though.
-
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)
-
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
-
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.
-
- Feb 13, 2023
-
-
Georges Racinet authored
It's been `gem push` all along
-
Georges Racinet authored
-
Georges Racinet authored
with Ruby lib generation, due to change in HGitaly specific protocol.
-
- Feb 12, 2023
-
-
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`.
-
- Feb 11, 2023
-
-
Georges Racinet authored
A good thing here compared with the first implementation from the Rails app is that we don't need to reimplement the various boolean mappings of Mercurial configuration: we can simply load the managed file only in a brand new `ui` instance. This the place though were we need the distinction between a value that is recorded in the file to be equal to the default or inherited one and a value that is plain missing
-
Georges Racinet authored
This is the implementation with full Mercurial configuration resolution.
-
- Feb 12, 2023
-
-
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.
-
Georges Racinet authored
with subsequent release instructions.
-
Georges Racinet authored
There are changes in protocol coming around, including of our own specific services.
-
- Feb 11, 2023
-
-
Georges Racinet authored
Will be nicer for the forthcoming tests
-
- Feb 13, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
In case we'd ever need to make a special Heptapod release (migrations…), we could use HGitaly 0.30.0
-
Georges Racinet authored
-
- Feb 12, 2023
-
-
Georges Racinet authored
The change is bigger in the Ruby library than it is in the Python lib and server implementation. With Ruby, it unlocks in particular the usage of `optional` fields (`proto3`, no longer experimental). With Python, however, protobuf versions 3.21 do not exist, so we keep it at 3.20. Gitaly Comparison tests so far tell us that it works.
-
- Feb 13, 2023
-
-
Georges Racinet authored
Same as in `py-heptapod`, simply backout this changeset when ready. HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: Leave message empty to abort commit. HG: -- HG: user: Georges Racinet <georges.racinet@octobus.net> HG: branch 'default' HG: changed .gitlab-ci.yml
-
Georges Racinet authored
As explained in #108, Gitaly now can provide rich errors as response "trailing metadata". We don't implement these, but we can already check that we don't miss any. Since the test passes, it means that all that would be relevant to the subset of protocol that we implement are still behind feature flags that don't default to `true`.
-
- Feb 12, 2023
-
-
Georges Racinet authored
There are always some protocol changes, even minor, and they warrant a new minor version.
-
- Nov 20, 2022
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Nov 19, 2022
-
-
Georges Racinet authored
We don't use functions meant for early return any more. Some more precise exceptions can still be useful, if there is possibility for catching them.
-
Georges Racinet authored
Using `context.abort()` makes it of course much simpler. This is the final actual effort to switch to the exception-style treatment. Closes #99
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
In this case there was a complication: `error.Abort` actually just raises `Exception()` which is hard to tell apart from other instances of `Exception` (usually in subclasses though).
-
Georges Racinet authored
-
Georges Racinet authored
Leaving only `not_implemented()`, which is more interesting. The warning log levels and more generally automatic logging will be better treated with interceptors.
-
Georges Racinet authored
Again from generic to specific, and lexicographic within each category
-