PermissionBackend is supposed to only perform permission
related checks. The 'isPatchSetLocked' check is a patch
set status check to decide whether a change is able to
be rebased, abandoned, etc. It's not permission related
and thus should be moved out from the ChangeControl.
This commit moves the 'isPatchSetLocked' method to the
PatchSetUtil class which looks like the best destination
of this method.
After this move, each time the caller tries to check
the REBASE/ABANDON/RESTORE/ADD_PATCH_SET permission, it
must verify the patch set of the change is not locked. If
it's locked the request should be rejected directly without
checking any further permissions. This commit makes sure
every existing usage has done this prerequest check in
advance.
Change-Id: Ic5cef11228f152cb3f51eea0a7aee100332f263a
ChangeJson will need some more work until we can enable parallel
formatting. Until then, a new boolean config option can gate the
experimental feature.
Change-Id: I5cdd05a409194c1fcf98d06de0c98c1be88939ff
* stable-2.15:
Fix the online index for changes when upgrading ES gerrit site
Update git submodules
Update git submodules
config-mail: Remove redundant colons from section titles
Change-Id: Ia424576f92edb038d4581d484d90a6378432ea9d
* stable-2.15:
CommandExecutorQueueProvider: Fix singleton binding
ReviewerinPredicate: Only return users in state REVIEWER
Remove documentation about cleaning the build cache
AbstractQueryChangesTest#reviewerin: Expand to cover CC
Change-Id: I8bc29e2635480ab975bc1a474b333f048bce4eae
These will be useful for some large tests for the googlesource.com
implementation, which wants to manually call the keySerializer/
valueSerializer.
Change-Id: I5037e3edd5dcead49eeb53dd8ae3b6f5a139d7e5
This reverts commit eb4d2d8da7bfc29511154fffe19f89f769a6a03c.
Reason for revert:
we observe
com.google.template.soy.tofu.SoyTofuException: In 'print' tag, expression "$instanceAndProjectName" evaluates to undefined.
at com.google.gerrit.server.mail.template.ChangeSubject(ChangeSubject.soy:9)
in production
Change-Id: I1701b5bcb4720086783536c5c987866bf73e54f4
The check for duplicate emails can be too slow if there are many
external IDs. E.g. this can make the login of users very slow.
This reverts commit ce80b6ca7752420a0f7a0ef8e05ef8d5a5c9add0.
Change-Id: I80c5f60203f97230e4d94c9c89d88323db403604
Signed-off-by: Edwin Kempin <ekempin@google.com>
The flipside of switching to a new serialization format that, unlike
Java serialization, doesn't store the version in the serialized
representation, is that we need to manage versioning on our own.
Define a version field in PersistentCacheDef, and store this in a new
column in the H2 database. This puts slightly more burden on the cache
implementation to manually manage versions, but makes the process of
updating caches safer; the latter happens much more often than the
former, so the extra up-front effort is worth it.
For existing caches using Java serialization, continue using the default
version of 0. This keeps the same invalidation semantics, and we can
bump the version to 1 when we start implementing new serialization
strategies.
Change-Id: I0d9cccea713fe6dcf368d8b95be59465c336bbb3
We want to have finer control over when persistent cache data is
invalidated due to the stored format changing. Depending on the Java
serialVersionUID, as we have done in the past, has two significant
downsides:
* Adding new fields which can have a reasonable default, or removing
old obsolete fields, always requires bumping the serialVersionUID and
thus flushing the cache. With an alternative serialization strategy
like protobuf, we can continue reading old entries in some cases.
* Trivial refactorings which do not change the data semantics, such as
renaming classes or fields, also flush the cache.
Both of these types of cache flushes have happened to PatchListCache in
the past year. Other serialization strategies such as protocol buffers
allows us to avoid unnecessary cache invalidations.
This change introduces a new interface CacheSerializer, which is used to
convert arbitrary objects to and from a simple byte array. This is
backwards compatible with the existing OTHER column type in H2, which is
implemented as a byte array, and accepts arbitrary data written with
PreparedStatement#setBytes and similar, not just #setObject.
Each SqlStore instance has a pair of CacheSerializers for the key and
value types. However, note that when the key type is String, the
existing StringKeyTypeImpl does *not* use a CacheSerializer for
serialization, since unlike the OTHER column type, the VARCHAR type
cannot just take a simple byte array. In the long term, it may make
sense to drop the KeyType class entirely, and instead use the
CacheSerializer to convert to bytes even for strings.
Change-Id: I150c1c8b8cd35b98c1a0792572d2e1ded4172774
The persistent cache definition contains all the same configuration
options as the non-persistent definition, plus more that apply to only
persistent caches. Currently, there is just one option, diskLimit, but
in the future there will be more.
Change-Id: I2079e485fe4d61a470b6dd32429acccdf8591b36
The CacheBinding interface now contains only setters. With "binding" in
the name, it indicates that this is the thing used from within
CacheModule to configure the interface.
Move all the getter methods into a new interface, CacheDef. This is the
type that is passed into {Memory,Persistent}CacheFactory, where the
cache setup internals need to query the configured values, but calling
setters at this point would be programmer error.
This has the side advantage of eliminating the need for throwing
RuntimeExceptions from H2CacheBindingProxy, and it is now clearer that
this is simply a delegate for the getter half of the interface.
Both of these interfaces are still implemented by the same CacheProvider
class, and it still retains the freeze-during-get behavior. It may be
possible to split it up, for example converting it to a normal builder
which produces a read-only CacheDef from its build method, but I wasn't
able to get that working with the asEagerSingleton binding magic used by
the current implementation.
Change-Id: I5c90f6eb17d257a127b2c52d70558c2f80655ec2
We usually use a direct executor in tests as it is hard to catch
multi-thread bugs in tests since they usually just result in a flake.
However, the improvements in ChangeJson and AccountCache are new and
at least for now it'd be nice to get *some* test coverage on
parallelization.
Change-Id: I5697f6b4fdf92dabbbe924f234a0d4c1e4e3a48c
These methods are called from ChangeJson which runs formatting in
parallel. Since these methods modify local variables that are not
thread-safe, they need to be synchronized.
Both methods modify distinct variables so that an overall
synchronization is not required.
Change-Id: I328dc1265c3329f2c7ad66fb5946f30ca4e5f3b8
The Create Change API currently supports the ability to specify
a `base_change`, and the change which you create will use that
existing change as its parent. However, it has no support for
specifying a commit sha1 which already exists on the target
branch.
This change introduces a new `base_commit` field, which takes
a 40 character sha1 as its value. It also introduces processing
to validate that the given sha1 is valid and exists on the
target branch. In also includes documentation and tests for the
above behavior.
Bug: Issue 8857
Change-Id: I7f1daa008b9a8d144c745327495dac65f581a5bf
Gerrit 2.15 released a new version of the change index that contains the
ASSIGNEE field. We can remove this check now since when people upgrade
to Gerrit 2.16 (which will include this commit) they will have the
ASSIGNEE field available in their index.
Change-Id: I56fb285ca31219d024babc043d64ef050e701c53
The PrologMachineCopy field in ProjectState was an obtuse way of
upgrading the weak reference stored in the RulesCache to a strong
reference. Now that RulesCache stores strong references on its own, we
can just call into RulesCache at exactly the time it's needed, namely in
PrologRuleEvaluator.
Moving this out of ProjectState helps with untangling the cacheable and
non-cacheable pieces of this class; for context, see:
https://gerrit-review.googlesource.com/c/gerrit/+/167053
Change-Id: I4beda2c9ddcf0014c606c0bee01ec49dde419361
Previously, PrologMachineCopy instances were stored with weak references
in RulesCache's internal cache, which had no other size constraints.
Instances were copied as hard references to ProjectState on demand,
meaning we would only spend memory on PrologMachineCopy instances that
were active in a project we care about in the cache. This was an awkward
and non-obvious two-layer cache.
We can achieve very similar memory performance if we simply convert
RulesCache to a standard Guava cache with hard references, sized to the
number of projects in the cache. Typically, we will store up to one
PrologMachineCopy per project in the cache, and the project cache is
generally sized to the total number of projects in the site. We can let
them expire out of the RulesCache in normal LRU fashion.
Under this implementation, it's possible we will hold on to stale rules
longer than necessary, particularly if rules.pl changes frequently and
the project cache is sized much larger than the total number of
projects. This could be avoided if we convert RulesCache to a
Cache<Project.NameKey, Pair<ObjectId, PrologMachineCopy>> and revalidate
the ObjectId on load; but at this point, that's a premature
optimization.
Tie the configuration of the RulesCache to the ProjectCache, so that it
is sized appropriately. This means that it can't be configured
independently, but we still need to at least mention it in the
documentation, since it will show up in the list of caches exposed to
administrators at runtime.
Change-Id: I1d3e3c013c30dd6d8a2a5d12f45a8e276d6051cd
Add a variable `instanceName` to the variables offered in the subject
template.
Remove the instanceAndProjectName as it is easy to reconstruct it using
the projectName and instanceName variables. It was also incorrect, as
it relied on the short name and not on the project name.
It was introduced recently, so _I_ don't think any gerrit instance will
break.
Change-Id: Iaf46fcbc1df6db637cb95711bac84a4ead5fc036
Duplicate permissions in an access section are not allowed. This is why
AccessSection#setPermissions(List<Permission>) fails with an
IllegalArgumentException if the provided list contains duplicate
permissions. However by calling AccessSection#addPermission(Permission)
it was possible to add duplicate permissions.
Duplicate permissions on an access section of the All-Projects project
make the permissions of the All-Project project unreadable and Gerrit
effectively stops working. This is because
ProjectState#getLocalAccessSections() filters out some permissions on
the All-Projects project by getting the list of permissions from
AccessSection and setting the filtered list back on AccessSection. If
the list that was retrieved from AccessSection contained duplicate
permissions, setting back the list failed with IllegalArgumentException
since AccessSection#setPermissions(List<Permission>) doesn't allow
duplicate permissions.
Also see change I29298232a3 which demonstrates this bug.
This change makes the behavior of the methods in AccessSection
consistent, AccessSection#setPermissions(List<Permission>) and
AccessSection#addPermission(Permission) now both reject duplicate
permissions.
The caller of AccessSection#addPermission(Permission) that tried to add
duplicate permissions was removed by change I139ba7aa97 which reverted
the in-place migration of refs/for/ permissions. When this code is added
back the new implementation must care about merging duplicate
permissions, otherwise the migration code will now fail.
In general it's better to fail at this earlier stage and prevent the
creation of a AccessSection with duplicate permissions as this prevents
that such a bad AccessSection is ever stored.
Change-Id: I5222cd9174f0b17baae2e66702c4aec6133a14ba
Signed-off-by: Edwin Kempin <ekempin@google.com>
By replacing the name from "setUp" to more explicit names, like
"setUpTestPlugin", we make sure nobody uses the name "setUp" by mistake,
thus overriding and cancelling the positive effects provided by the
base test class.
Change-Id: I0f74b437589e3b837343e4648d3679b34875109c
