- Jul 05, 2021
-
-
Georges Racinet authored
-
- May 31, 2021
-
-
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.
-
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.
-
- Jul 01, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Mar 21, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 20, 2021
-
-
Sushil Khanchi authored
-
- Jun 17, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Seen for the the first time in GitLab 13.12 context, as in the new test. Probably a call somewhere that doesn't bother to check for emptiness first.
-
Georges Racinet authored
-
- Jun 16, 2021
-
-
Georges Racinet authored
-
- May 26, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
mostly to make obvious it's been done and perhaps limiting the number of conflicts in .hgtags
-
Sushil Khanchi authored
-
- Mar 25, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 23, 2021
-
-
Sushil Khanchi authored
-
- May 25, 2021
-
-
Georges Racinet authored
This demonstrates how to use `message.Logging`. It is still quite partial, but we can generalize later, and make logging of incoming requests more systematic.
-
- Apr 04, 2021
-
-
Georges Racinet authored
With gRPC, the `repr` of messages, notably Gitaly Requests is made of multiple lines. This is very bad for logging: a log should always be made of a single line for: - meaningful grepping - detangling when several processes log to the same file We want in particular service method to be able to log easily their incoming requests and/or more messages, but we want the formatting to be done only if the log is actually to be emitted (important to avoid debug logs to make production servers choke). This is usually achieved with the following pattern, because logging evaluation is inherently lazy. ```python logging.debug('the interesting object is %r', obj) ``` We could use extras, as `hg-loggingmod` does for the repository, but that is evaluated in the final formatting of the entire log line, and requires to register a specific format, then a specific handler to use it. The provided solution (wrapping in a class), is not zero-cost, but is expected to be cheap enough for the time being.
-
- May 18, 2021
-
-
Georges Racinet authored
This goes with the general preparation for Heptapod 0.22 and comes with interesting diff options.
-
- Apr 25, 2021
-
-
Georges Racinet authored
Now that everything is back to normal, it is mandatory again.
-
Georges Racinet authored
This was covered by Gitaly comparison tests, but not by direct tests. The resulting CI failure was masked by the temporary incompatibility of hg-evolve stable with Mercurial stable due to the latter being bumped to 5.8rc
-
- Apr 24, 2021
-
-
Georges Racinet authored
-
- Apr 22, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Nothing of consequence to us: - more comments - removal of `name` field for Git remotes (mirrors-related) operations
-
- Apr 11, 2021
-
-
Sushil Khanchi authored
-