Test logging is already activated in test derived from
AbstractDaemonTest. Extract the code to activate the test logging in
new TestLoggingactivator class and also activate the log for tests
derived from GerritBaseTests class.
Also document in dev-bazel.txt how to increase log level for tests from
IDE and from Bazel.
Also remove some superfluous white spaces from dev-bazel.txt.
Change-Id: I7641bfcffa35e36c0330dc9244ceafd8366159ca
This reverts commit c54e6b5bfd4644ba06292af6a2a961cecda7ab28.
Reason for revert: A similar feature to increase the logging level was
already added by: I00c203419db. Instead of adding a dedicated handling
of logging for query tests only, logging activation and configuration
should be generally extended to all tests derived from GerritBaseTests.
Change-Id: I7be6b13dcc74f5a108b5e32e4b0e7a8dec489963
The log level for the 'com.google.gerrit' package when running tests can
now be controlled by the 'GERRIT_LOG_LEVEL' system variable.
Alternatively if the system variable is not set, the log level can be
also set by the 'gerrit.logLevel' system property. Allowed values are
DEBUG, INFO, WARN, ERROR, FATAL, OFF, TRACE and ALL (case-sensitive,
also see org.apache.log4j.Level).
If not set, or set to an invalid value, the default log level is INFO.
Once the CI server was adapted to set the system variable we may change
the default log level back to DEBUG so that debug logs are generated
when running tests locally (we had to lower the log level from DEBUG
to INFO because the log amount was too large for the CI server to
display, see Change I6b13ee504).
Bug: Issue 11953
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I00c203419dbdff568f51bbdcc2edeaf0b8fa7df8
This reverts commit a73d761b8a6cbf1626e7daf83214ea94b5e18960.
Reason for revert: log level for tests was reduced to INFO per default
in I6b13ee50459.
Moreover, the search in: [1], reveals that there is no usages of this
annotation in gerrit core and plugins.
[1] https://cs.bazel.build/search?q=r%3Agerrit+LogThreshold
Change-Id: Ic3b1d7bb06bd5a49870ec2ff44982cdced150091
The amount of logs that is generated by running the tests is too large
to view it on the CI. Loading a build log in the browser takes so long
that it becomes unusable. This makes it difficult to find the reason for
a failed build/test on the CI.
As this is affecting daily development we need to resolve this quickly,
hence let's reduce the log level for tests to INFO for now.
Having debug logs available to investigate a test failure is good, but
debug logs for passing tests are not useful. Ideally the CI would just
hide debug logs of passing tests, but while the CI doesn't have this
capability we can only reduce the log level for now.
This also affects the log level for running tests locally.
Bug: Issue 11953
Signed-off-by: Edwin Kempin <ekempin@google.com>
Change-Id: I6b13ee50459bec18ef1c701fe30c992634ed26d5
Due to this Bazel issue: [1] non .class file entries are normalized in
singlejar Bazel utility. As the consequence even JavaScript and HTML
files have the timestamp: 2010-01-01 00:00. This makes it problematic
to refresh the plugin artifacts in browser because of the cache if a
new plugin version is deployed in Gerrit server.
To rectify, touch the content of the plugin artifact in stamp action.
The 'touch' command uses the system default timezone if none is
supplied. This makes zip files dependent on the timezone of the
generating machine.
Zip by default stores extended attributes (eg. ctime, atime) on Unix
systems. These can be further sources of non-determinism, so switch it
off with --no-extra.
[1] https://github.com/bazelbuild/bazel/issues/10789
Bug: Issue 12349
Change-Id: Ifcb027f42c20f785f14e9933c061af27285e99c4
Adapt JGit metrics to new WindowCache metrics introduced in JGit 5.1.13:
- cache_used: replace use of deprecated method
- open_files: adapt type which changed from int to long
Add the following new metrics:
- avg_load_time
- eviction_count
- eviction_ratio
- hit_count
- hit_ratio
- load_failure_count
- load_failure_ratio
- load_success_count
- miss_count
- miss_ratio
- cache_used_per_repository, limited to the top 1000 repositories having
most data cached
Change-Id: I6d4c76a85943ea23d57d15d4f6bdeb91711a1a63
JGit 5.1.13.202002110435-r adds
- new WindowCache metrics
- and enables using strong references to reference cache pages in the
WindowCache. Set core.packedGitUseStrongRefs = true to enable using
strong references to reference packfile pages cached in the WindowCache.
If this option is set Java gc can no longer flush the WindowCache to
free memory if the used heap comes close to the maximum heap size. On
the other hand this provides more predictable performance.
Change-Id: I895369a8596dfc5adce76c65202ecf37e6a8386d
BucketedCallback enables defining compound metrics having a set of
sub-metrics along a dimension. This is used e.g. in CallbackMetric1
where the additional type parameter F1 defines the type of this
dimension. For each of the values of this dimension present in the
current dataset of the compound metric BucketedCallback registers a
corresponding metric in DropWizard's metric registry which isn't aware
of the relationship between a compount metric in Gerrit and the
corresponding sub-metrics.
If another measurement yields a new metric dataset which no longer
contains some of the earlier registered sub-metrics doPrune() did remove
these stale sub-metrics from the "cells" collection but missed to remove
them from DropWizard's metric registry. This had the effect that such
stale metrics no longer present in the current dataset were still
reported via the used metrics reporter plugin albeit the underlying
monitoring dataset didn't contain that data anymore.
Fix this by removing the stale sub-metrics also from the DropWizard
metric registry.
Change-Id: I767530f57883379c976614705241cbd1d1597541
Draft comments refs are stored in the "All-Users" repo under a special
ref with the form refs/draft-comments/$change_id_short/$change/$user.
Previously, ref updates used fast forward updates for all operations
(add draft, delete draft, edit draft), and the new commit pointed to the
last commit of the ref. This behavior caused draft deletions to persist
in history.
In this change, the implementation of the change draft update is
modified so that new commits point to an empty parent list, causing
draft deletions to be garbage collected by git after a period of time.
Change-Id: Ifbb7ad2fe1b1370eac30feb3fe7b181cbb626257
When no other ref than a RegExp with a gerrit username or shardeduserid
pattern, the permission is not properly validated and repository access
is denied.
With change Iedf3022f6c, calling shortestExample on regexp+parameters
refs produces a reference that won't match the username or the
shardeduserid.
For a reference like : ^refs/heads/users/${username}/.+
we will have the following:
'refs/heads/users/user1/my_branch' vs
'refs/heads/users/_PLACEHOLDER_/my_branch'
When we remove shortestExample, we have to modify Regexp and
ExpandParameters to skip the regexp start anchor caracter when comparing
against the prefix, or to compare regexps themselves.
Bug: Issue 3340
Change-Id: Id6a890a91c5d6d954dab74694c2d3fd53c15897c
The special regexp caracters ('{', '}') from gerrit pattern are causing
an exception. As ${username} and ${shardeduserid} are only meaningful to
gerrit, we substitute them for placeholders.
Unlike what is done in RefPatternMatcher.ExpandParameters, the
placeholder does not contain ':' but '_' to be correctly evaluated by
Repository.isValidRefName later on.
Bug: Issue 3340
Change-Id: Iedf3022f6ce3068f7e9534f224cf05bb99b0f970
Allow optionally enabling DEBUG level logs for Lucene and Elasticsearch
query tests. It occurs in the form of a command passed to the JVM before
tests start. Tests will only emit INFO level logs if not enabled.
Enable rootLogger default INFO log level after tests conclude.
Add missing log4j-config rule which includes log4j.properties in BUILD
files.
Update online Gerrit documentation to explain how to optionally enable
DEBUG log level for these specific tests.
Bug: Issue 10498
Change-Id: I75492de1c5ef8721ae745266e36b8cbfb0b67682
This occurs very frequently and the cause is always the same, so
logging with the stack trace spams the logs making it difficult
to find stack traces that are caused by real issues.
Change-Id: I6acc32937ee647337337f99309947b0d414dffad
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
In order to enable detailed performance and problem analysis add
upload-pack metrics to the sshd log. The log format for upload-pack log
records is now enhanced to:
- timestamp
- session id
- thread name
- user name
- account id
- message
- command wait time
- command execution time
- time negotiating
- time searching for reuse
- time searching for sizes
- time counting
- time compressing
- time writing
- total time in UploadPack
- bitmap index misses (-1 means no bitmap index available)
- total deltas
- total objects
- total bytes transferred
- client agent
If statistics aren't available e.g. since an exception occurred they are
logged as -1.
Change-Id: I4ec08579cedfeb6a30eb41d2e2a110f4f8eee8fa
The option may be specified multiple times, but this is not explicitly
clear in the documentation.
Change-Id: I33a6030b00a24f578c79cdd369bff246fd4470b0
* changes:
Fix method name to register custom event types in plugins
Don't send mails on publish change edits for WIP changes
PatchSetInserter: allow to set "sendEmail" bit
With this new "sendEmail" bit, we will have more control
for whether emails are going to be sent out after a new
patch set is added. This is useful for avoiding duplicate
emails, e.g merge (already have an email to notify a change
is merged, no need to have another email to say a new patch
set is uploaded).
Change-Id: I43c5d7c6560316d5a6034dc8e711f7e87b7af932
Use enableCreateNewChangeForAllNotInTarget() from AbstractDaemonTest
instead of duplicating the code.
Change-Id: Ic2fe137533a7b6ad33fc1705947473766730bf56
If Change-Ids are computed from the commit content and timestamp it can
happen that 2 changes get the same Change-Id. E.g. this can happen if
the Create Change REST endpoint is used to create empty changes in
parallel. In this case the base commit, the commit content (empty) and
the commit timestamp are the same, so that the same Change-Id is
computed for several changes. This also means that the commit message
and hence the commit SHA1 can be identical between the changes. If in a
follow-up steps identical change edits are published in parallel on
these changes you can even get non-empty changes for the same commit
SHA1. Having multiple changes for the same commit SHA1 (and with the
same target branch) is an inconsistency in Gerrit that Gerrit cannot
deal well with (e.g. this causes issues during submit).
To prevent such duplicate Change-Ids we are now randomly generating
Change-Ids. This means 2 parallel Create Changes requests will use
different Change-Ids even if the commit content and timestamp is the
same. A new test does parallel calls to Create Change REST endpoint and
verifies that commit SHA1's of the created changes differ (they differ
because in the commit message we have different Change-Ids now). When
the Change-Ids were computed from the commit content and timestamp this
test failed.
Also cherry-pick Change-Id: I9de36332 for keeping the secure random
generation out of the GWT-related code and minimise the conflicts
with the merge upstream.
Bug: Issue 12246
Co-authored-by: Luca Milanesio <luca.milanesio@gmail.com>
Change-Id: Ie4f01e5a32b1efca58f8b443ff046623f0e5f188
(cherry picked from commit 73163490b75a8d39aaa2eb60ba2de0cb27f6ba70)
Bazel supports both BUILD and BUILD.bazel files and in this issue: [1]
there is a discussion to prefer BUILD.bazel over BUILD naming
convention. Detect BUILD.bazel files as Python code in addition to
BUILD files.
[1] https://github.com/bazelbuild/bazel/issues/4517
Change-Id: Iabc719b914fcd08ef6e73c314f09f924540c3794
Follow-up change for be4184f7 which missed documentation. Also names of
newly added metrics didn't align with existing metrics for REST API.
- add documentation for the jetty metrics
- improve descriptions of the jetty metrics
- rename jetty thread pool metrics from httpd/jetty/* to
http/server/jetty/* in order to align metric names with already
existing REST API metrics
Change-Id: I1d4eabec91749f28d09df7d2d29606b133fefc4d
This change adds an UI element that displays messages registered with
the MessageOfTheDay extension point. The messages will be displayed
below the main navigation header. This functionality was already part
of the GWT-UI, but was never migrated to the new UI.
The messages can be dismissed by a button click, that will create a
cookie that will prevent the message from being displayed again until
the redisplay time configured with the message.
The content of the message can be HTML. Depending on where the message-
content is coming from, this might be harmful. In case of the
messageoftheday plugin, the message is added as a config from the Gerrit
server site, which can probably be considered save. However, in a future
change rendering HTML should be made configurable and switched off by
default. Text should then be rendered using `gr-formatted-text`.
Change-Id: I2cbbcbcd49734b645701b9fac62a016a269d37f2
