- 05 Jul, 2021 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- 31 May, 2021 2 commits
-
-
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.
-
- 01 Jul, 2021 2 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- 21 Mar, 2021 2 commits
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- 20 Mar, 2021 1 commit
-
-
Sushil Khanchi authored
-
- 17 Jun, 2021 5 commits
-
-
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.
-
-
- 16 Jun, 2021 1 commit
-
-
- 26 May, 2021 5 commits
-
-
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
-
- 25 Mar, 2021 2 commits
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- 23 Mar, 2021 1 commit
-
-
Sushil Khanchi authored
-
- 25 May, 2021 1 commit
-
-
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.
-
- 04 Apr, 2021 1 commit
-
-
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.
-
- 18 May, 2021 1 commit
-
-
Georges Racinet authored
This goes with the general preparation for Heptapod 0.22 and comes with interesting diff options.
-
- 25 Apr, 2021 2 commits
-
-
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
-
- 24 Apr, 2021 1 commit
-
-
Georges Racinet authored
-
- 22 Apr, 2021 10 commits
-
-
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
-