GetReflog uses Repository#getReflogReader, but this is not implemented
by DfsRepository which is used in the test framework. As a result, calls
to this API method from tests results in UnsupportedOperationException.
Modify GetReflog to catch the UOE and rethrow as MethodNotAllowed, so
we get a graceful failure rather than "internal server error".
In the tests, expect MethodNotAllowed, with a TODO to rework when/if
the implementation of getReflogReader is done in DfsRepository.
Change-Id: I0d0d718ca4e4ecf2c544ea6e912397c20e2fd7e3
This change extends the existing cherry-pick endpoints to allow
users to specify the base commit of the cherry-pick destination.
If the base commit represents a visible change revision on the
destination branch, the change status must be either 'New' or
'Merged'.
Alternatively, the base commit can be a merged commit on the
destination branch with no change associated with it.
Change-Id: I6721a2d88f4b73058dc1abf3e85c4184e46088c5
* changes:
Highlight hunks which are due to rebase on PolyGerrit
Copy due_to_rebase to subgroups in gr-diff-processor
Move diff tests from RevisionIT to RevisionDiffIT
Mark hunks which are present due to a rebase when diffing patch sets
So far it only checks that preferred emails are backed by
corresponding external IDs. E.g. change I2b3c5c9d assumes that each
preferred email exists as external ID.
Change-Id: I824caa34545b1ba147fb71ede503104ba1d5481c
Signed-off-by: Edwin Kempin <ekempin@google.com>
The diff between two patch sets contains hunks which weren't
introduced by either patch set if a rebase occurred between those
patch sets. Previous optimizations for this case simply omitted all
files which aren't touched by either of the patch sets.
This change goes one step further: All hunks which can clearly be
identified as being introduced by a rebase are marked. In case of
doubt (e.g. they overlap with a regular hunk), they aren't marked.
To be consistent with the previous behavior, we exclude all files from
the result which only contain hunks due to rebase. In some cases (e.g.
a patch set touches 'fileA' but all identified hunks were introduced
by the rebase), this rule can be stricter than the previously mentioned
(as the previous rule would still show file 'fileA' but we exclude it
now).
Hunks which are introduced by a rebase are identified by computing
the diff between the parents of the two patch sets and transforming
the result to differences in terms of treeA of patch set A and treeB
of patch set B. This follows a suggestion which was posted as a comment
(https://gerrit-review.googlesource.com/c/33091/5//COMMIT_MSG#7) in
change I63d3a21ad4f.
As we always determine which hunks are introduced by a rebase when
two commits are explicitly specified which don't share a common
parent, we will determine those hunks even when we compute the
diff between the parents of the patch sets provided that those
parents fulfill the condition of being separated by a rebase. Those
situations should be rare and hence we refrain from adding
optimizations for this case for the moment.
Bug: Issue 217
Change-Id: If06381d506d360f0e3d24d078dcb54692698e766
* stable-2.14:
Document how to set default UI
Note on branch-specific labels with custom rules.pl
GWT UI: Allow to set blocking label range rules
Extend LFS plugin servlet so that Git LFS 2.0 Lock API is handled
PolyGerrit: Fix undefined url in gr-dropdown
Change-Id: I01320e404daf1abd052c39321346e2eacff3dd09
The change extends LFS serve regex so that the following operations are
handled (according to [1]):
POST /locks - create lock
GET /locks - list locks
POST /locks/verify - list locks for verification
POST /locks/lock_id/unlock - delete lock
Common LFS definitions, like paths, regexps, content type, etc., were
moved to gerrit-extension-api so that they can be shared between Gerrit
core and LFS plugin.
[1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/locking.md
Change-Id: I8299000c827b5a34d6de1ed5fc650f74be4164a2
Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>
This change adds support for a new change identifier in the /changes
REST API endpoint. It follows the discussion on
Idac92e61ee1471b074034eef39901b1b8e961706 and the two recent Gerrit
Hackathons.
The new change identifier serves multiple purposes:
1) Since it contains the project name, we can directly construct the
ChangeApi without a secondary index lookup. This means that we can
still serve requests to some endpoints, even in case of a complete
index failure.
When the project is added in the UI, we will still be able to serve
change pages in case of an index failure. While the triplet also
contains the project, it is unfeasible for the UI since it requires a
branch name (which we don't want to have in the UI URLs) and has the
changeId instead of the change number.
2) Reducing the number of secondary index lookups is a performance gain.
3) The project name being contained in the URL enables load balancers
to shard requests based on the project without a need for an index
lookup (which most load balancers do not support). The sharding
configuration can then be as easy as a regular expression and a
static project-to-machine mapping.
4) This change is also a first step in deprecating the other three
change identifiers and unifying our API access pattern. This will
happen gradually in upcoming changes. Also the UI will be adapted.
This change also adds extensive testing to both the new parsing logic as
well as all change identifiers in both the Java and the REST API.
Change-Id: I7a904fdd001c065af9897d9c08edce1cfbd43a14
Default permission backend unconditionally considers administrator
credential when checking for plugin capabilities. This may not always
be what plugin authors want. Make it configurable, but preserve the
current default to be true. Now, different behaviour can be expressed
with:
@RequiresCapability(
value = AccessCiDatabaseCapability.ID,
fallBackToAdmin = false
)
Change-Id: Id16bfb539d22f47388e3d5464211128987276254
This change includes tests for the new API which increases the test
coverage for GetCommit from 25% to 94%.
Change-Id: I19457b47bc92f846446a2fc7d3a9127aeaae476d
Signed-off-by: Edwin Kempin <ekempin@google.com>
The API includes some new classes since 2.14 and we need to be able
to build snapshot artifacts to test plugins that use the new classes.
Change-Id: Ifad31b93e5b5068c0d6952582f6882edc252e227
This change adds support to set notification options for the existing
cherry-pick change/commit REST endpoints.
Change-Id: I3b419a4d68ea186092163cddd354b5bf4de0daeb
This change adds a new interface 'NoteDbRewriter', which can be used to
rewrite the NoteDb commit history in BatchUpdate.
By implementing the new interface, this change allows users with
administrate server capability to delete a comment by replacing the
comment's message.
To delete a whole comment, the rewritter is required to update the
commit message, which contains the number of the comments put in by the
original commit. This can be done in later changes when necessary.
Bug: Issue 4445
Change-Id: Icaeb3c24f5dc88f6b44b1297366a692a32676910
This allows users to explain why the private flag on a change was
set/unset.
Since the requests to set/unset the private flags can have a request
body now, POST is more appropriate than PUT. Changing this is okay,
since the support for private flags was not released yet.
Since some proxies prohibit request bodies for DELETE requests offer
deletion of the private flag also as POST request on
/changes/<id>/private.delete.
The setPrivate method in ChangeApi is changed, which is okay since it
wasn't included into any release yet.
The UI doesn't offer to specify a message yet when the private flag is
set/unset but this may be implemented in a follow-up change.
Change-Id: Ib201114ffa397a313bca565d7fb52767b4c9197c
Signed-off-by: Edwin Kempin <ekempin@google.com>
* stable-2.14:
Create group-indexed extension point
Always use SSL implicitly for POP3 and IMAP
InitSshd: Check if the ssh_host file exists with the other keys
Change-Id: I1ad22d5566314865c0c03bcf31f7802b653e82fa
The new endpoints wrap the existing star endpoint, making it easier for
users to mute changes by a simple PUT, without input, rather than
having to construct a POST request with the necessary stars input.
The endpoints also provide "Mute" and "Unmute" buttons on the UI.
The buttons are not displayed for own changes.
Change-Id: Iab3de63e47bf7a850d8718febff326bc550c3abd
If the "mute/<patchset_id>"-star is set by a user, and <patchset_id>
matches the current patch set, the change is always reported as "reviewed"
in the ChangeInfo.
This allows users to "de-highlight" changes in a dashboard until a new
patchset is uploaded.
The ChangeInfo muted-field will show if the change is currently in a
mute-state.
Change-Id: I83085033ff99d7b0ce1fe834fabfad5956db90ae
Gerrit already allows a user to ignore changes (changes will be excluded
from incoming dashboards and email notification suppressed) but it is
not very accessible. The implementation makes use of the user stars API,
using a star with a specific label, "ignore". There is no UI for it, and
to ignore or unignore a change one must construct a PUT request with the
necessary input and manually send it by curl (or other means).
The new endpoints wrap the existing star endpoint, making it easier for
users to (un)ignore changes by a simple PUT, without input, rather than
having to construct a PUT request with the necessary stars input.
The endpoints also provide "Ignore" and "Unignore" buttons on the UI.
The buttons are not displayed for own changes.
Change-Id: Icbb226d7f5333a78fae27f2a4e5e6c86afd1f419
The check.access endpoint is for administrative users. It can be
supplied with a (project, account) or (project, account, ref) tuple to
check that ACLs are behaving as expected.
Change-Id: Icf74b0fc4036312eef9f222aaff8e1769a051eec
This CL updates the implementation of PostReview to replace
all instances of raising UnprocessableEntityException
(HTTP 422) with failed Additions instead. This matches the
docs for Set Reviewer, which no longer mention 422 being a
valid response code. This also falls in line with
RFC 7231, which promotes HTTP 400s with detailed bodies
over 422s.
It also updates the documentation to be clearer about
how these API functions work.
Bug: issue 6016
Change-Id: I1adad98107ba021132293ec47c6a6da01787556e
Allow plugins to define their own capability and permission and check
for current user satisfy them, consuming PluginPermission from the
plugin extension API.
Change-Id: Iabba0ffa2a7e40605b09b41c25ab147395bb5f8c
