commit c9a076d7cc8fe575c8e1fab02ad32a90c39db11f
author Edwin Kempin <ekempin@google.com> Thu Dec 13 09:03:37 2018 +0100
committer David Ostrovsky <david.ostrovsky@gmail.com> Fri Oct 11 10:41:09 2019 +0000
tree 8a3c6e6def6d4574ad2207d01537b1ffa7a21ac9
parent 1ca3f01418828fffb4eba19a9b579dd08daaa717

Support tracing on clone, fetch and ls-refs

If git protocol V2 is used clients can pass server options on clone,
fetch and ls-refs. Add support for a "trace" server option that enables
request tracing in Gerrit. E.g.:

  git fetch origin -o trace=123
  git ls-remote origin -o trace=456
  git clone --server-option trace=789 <URL>

Note the git clone doesn't support server options by '-o' since git
clone uses '-o' to set the name of the origin.

Tracing git clone, fetch and ls-refs only works if git protocol V2 is
used. This means v2 must be enabled in:

- the repository's .git/config:
  [protocol]
    version = 2
- on the client side, by either passing -c protocol.version=2, or
setting globally in ~/.gitconfig:
  [protocol]
    version = 2

Extend existing GitProtocolV2IT integration test to pass -o trace=<num>
option. As the consequence the trace context is created with this trace
id, e.g.:

DEBUG com.google.gerrit.server.permissions.RefControl : 'user' cannot \
perform 'read' with force=false on project 'foo' for \
ref 'refs/heads/secret' [...] [CONTEXT forced=true TRACE_ID="12345" \
project="foo" ]

However, it is not clear how to verify that the trace context works as
expected.

Another open question is how we could return a generated trace ID to the
client. For now this is left as a todo, because the tracing
functionality is already usable by setting the trace server option with
an explicit trace ID (as shown in the examples above).

Change-Id: I04662a352eb9ceccdbe25eb398289badd07492e2
Signed-off-by: Edwin Kempin <ekempin@google.com>