commit | b61a9228f235095dc13bc9cac04b4d9110919f2e | [log] [tgz] |
---|---|---|
author | Edwin Kempin <ekempin@google.com> | Thu Sep 23 07:35:51 2021 +0200 |
committer | Edwin Kempin <ekempin@google.com> | Thu Sep 23 11:54:19 2021 +0200 |
tree | 9a302b14683538eaab8a3f08c43245b5c657bc55 | |
parent | 621ff6abb6ef454c78d254c59b8273b7eab2aa56 [diff] |
Log caller when submit rules are evaluated and tracing is enabled Evaluating submit rules can be expensive, e.g. the code owners submit rules must do some significant amount of work as it needs to check for each file in a change who are the code owners and whether they approved the change. Invoking the evaluation of submit rules too often can lead to quite some extra latency (e.g. at Google we know of cases where plugins unintentionally trigger a lot of submit rule evaluations making requests very slow). At the moment from traces we can see how often submit rules are evaluated and how long the evaluation of the submit rules takes, however the trace is not telling us which code triggered the submit rule evaluation. Knowing this is important so that we can judge whether running the submit rule evaluation is expected (e.g. because the change is being reindex) or unexpected (e.g. a plugin uses the changes API to retrieve change details but doesn't need any of the fields that are populated by running the submit rules). To make the caller available we are logging it now on fine level, which means that it's being logged if tracing is enabled. To find the caller we use CallerFinder which inspects the current stacktrace to find the first interesting class in it. Please refer to the class javadoc of CallerFinder for details on how this works. In general using CallerFinder is fragile and can easily break, which is why it should only be used if there is a great benefit from logging the caller, which I think is the case here. I tested the used CallerFinder targets with calls from Gerrit core and plugins to verify that they are producing the right callers that tell us who triggered the call. Signed-off-by: Edwin Kempin <ekempin@google.com> Change-Id: Iebd3a23676b5564c3d5ccffd30130051542305ea
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 8 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-centos8
To run a Ubuntu 20.04 based Gerrit image:
docker run -p 8080:8080 gerritcodereview/gerrit[:version]-ubuntu20
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.