In an effort to make it impossible to use the ProjectCache interface the
wrong way, we are simplifying the interface to just a single option for
getting a project. The #get method throws a StorageException in case loading
failed and returns Optional#empty in case the project does not exist.
Change-Id: I7e3ecf2de3bc975d1c35ee8a848ac61def7af252
This is long overdue renaming step to manifest that SQL database is
removed from gerrit core. Moreover, client/server package division
was needed due to GWT UI that was removed as well in release 3.0.
Bug: Issue 11678
Change-Id: Icfd83a309a6affac54141e7284e70f1255537dc4
Since [1], included in JGit 5.3.0, TestRepository is AutoCloseable and
should be managed by try-with-resource.
[1] https://git.eclipse.org/r/#/c/134912
Change-Id: Id5fa8a47e1557ee2a5765aa13fc317f2f73ef5d1
This has two benefits:
* Saves a line in fluent call chains when updating All-Projects.
* May avoid the caller having to inject an AllProjectsName for the sole
purpose of passing to
projectOperations.project(allProjects).forUpdate().
Admittedly, the latter benefit is not really realized yet, since
acceptance tests are typically using the protected AllProjectsName from
AbstractDaemonTest.
Change-Id: Ib01cacf9a561c4644e8ad2fbbb7221dabbbe7acd
In order to implement this logic in TestProjectUpdate, we need to pass
the injected AllProjectsName and the current project name into
TestProjectUpdate. This is an implementation detail handled entirely
in-package, and is not part of the public TestProjectUpdate API
(although it does leak into the toString representation).
This requires changing the tests, which were incorrectly updating
global capabilities on arbitrary repos. A side effect is that we can't
check for the exact contents of the [capabilities] section, because the
site is initialized with more capability entries in All-Projects. Also,
the group names referenced in project.config are different, because the
groups file in All-Projects is also initialized during setup. (This is
the kind of brittleness we signed up for when phrasing the test
assertions over the contents of project.config.)
Change-Id: Ib96dd12612ff7e4bcc95f483e1ed53a803ba3972
The initial implementation used an exclusive bit on TestLabelPermission,
to reflect the only usage of this bit within AbstractDaemonTest. That
was actually the wrong level: the exclusive bit is not associated with a
group. Instead, add a separate method on TestProjectUpdate.Builder for
setting the exclusive bit on a per-(ref, permission) level.
This method reuses the existing TestPermissionKey, with some
restrictions on the allowed field. The additional potential for runtime
exceptions is outweighed by the convenience of reusing the existing set
of static factory methods to create builders.
Change-Id: I50f0072057d94c079b006fed7ecf997232e8d80d
These methods had a confusing array of method signatures. The new
TestProjectUpdate interface is much more explicit, easy to read, and
performant when updating multiple permissions at once. The cost is a bit
more boilerplate, but the improvements are worth it.
This change only inlines the non-looping implementations, as the latter
will require more manual editing.
In addition to the automated inline refactoring, made the following
manual changes:
* Combined adjacent calls into a single TestProjectUpdate.
* Remove redundant force(false) and exclusive(false).
Change-Id: I707b7f47ecfcc4cec62d1f822e115b15426f4027
Unlike when adding permissions, removing all of permissions, label
permissions, and global capabilities can be represented by a single
AutoValue type, TestPermissionKey. From the caller perspective, the fact
that they all use the same type is mostly an implementation detail: they
will still call a single method remove (cf. add) passing a builder that
they get using a static method like permissionKey (cf. permission). In
this case the remove method just has fewer overloads.
Change-Id: I0b001bb60ea419454faebdb29cf80eaa0655f1ed
Use a similar but separate AutoValue, TestLabelPermission, which has a
slightly set of fields from TestPermission. It might be theoretically
possible to combine them into an interface, but there would be no
benefit from a caller's perspective.
Change-Id: I70eb97e3c8af84086a3c1375fb2d0677bca0309d
The first usage of this utility will be to update permissions,
replacing com.google.gerrit.server.project.testing.Util.
Add permissions using a new TestPermission AutoValue, specifically for
tests. This API is intended for easy fluent use; the number of places we
set up permissions in tests vastly outnumbers the codepaths that update
permissions in production code.
This change adds the ProjectOperations implementation, adds a test for
the new functionality, and updates a small number of callers in real
tests to prove it works in the real world. Followup changes will migrate
more callers as well as add support for global capabilities, deleting
permissions, etc.
The old Util methods use a dangerous antipattern of returning the
mutable PermissionRule that is stored in the ProjectCache, which is then
mutated by callers. This new test API does not require mutating live
PermissionRules after initialization, and migrating all tests to use the
new API is on the critical path to making PermissionRule immutable.
Change-Id: I37148bdb297e5fd129e814ef4532a6ed5ffdc041
The general pattern for check methods is Config#getFoo becomes
ConfigSubject#fooValues, with the same argument list. A more fluent API
using intermediate types may be possible, but the goal to start with is
to keep the API close to the underlying Config APIs.
Change-Id: I09e6e04a5a77fd440ff34d3d284b1d69f8440695
