Merge branch 'stable-2.9'

* stable-2.9:
  Add support for JCE (Java Cryptography Extension) ciphers
  Buck: Respect gerrit-gwtui-common dependency for GWT plugins
  More improvements in the change info block UI
  Add a section about the submit type to the project owner guide
  Fix: Wrong exception mapping in ReceiveCommmits
  Fix REST example for removing included groups from a group
  rest-api-groups.txt: Correct input examples to use [] for lists
  Document project options
  Allow service users to access REST API if auth.gitBasicAuth = true
  Improve documentation about project creation
  Make singleusergroup a core plugin
  Rename 'Change Submit Action' in documentation to 'Submit Type'
  ProjectInfoScreen: Display submit type and content merge next to each other
  Add guide for project owners
  Improve description of the auth.gitBasicAuth parameter

Conflicts:
	Documentation/config-gerrit.txt
	Documentation/rest-api-groups.txt
	gerrit-gwtui/src/main/java/com/google/gerrit/client/GerritResources.java
	gerrit-gwtui/src/main/java/com/google/gerrit/client/admin/ProjectInfoScreen.java

Change-Id: I269f8f1395c352d8d90ba4f770a19296a50967de
This commit is contained in:
Shawn Pearce 2014-04-21 13:50:24 -07:00
commit 5c4d3ed332
20 changed files with 538 additions and 55 deletions

View File

@ -6,6 +6,7 @@ to those groups. Access rights cannot be granted to individual
users.
[[system_groups]]
== System Groups
Gerrit comes with following system groups:
@ -375,6 +376,7 @@ review is made. This functionality is provided by the review-notes plugin.
These are references with added functionality to them compared to a regular
git push operation.
[[refs_for]]
==== refs/for/<branch ref>
Most prominent is the `refs/for/<branch ref>` reference which is the reference
@ -818,6 +820,7 @@ by the 'Force Edit' flag. If this flag is not set the topic can only be
edited on open changes.
[[example_roles]]
== Examples of typical roles in a project
Below follows a set of typical roles on a server and which access

View File

@ -113,7 +113,7 @@ Defaults to MERGE_IF_NECESSARY unless
link:config-gerrit.html#repository.name.defaultSubmitType[
repository.<name>.defaultSubmitType] is set to a different value.
For more details see link:project-setup.html#submit_type[
Change Submit Actions].
Submit Types].
--use-content-merge::
If enabled, Gerrit will try to perform a 3-way merge of text

View File

@ -57,7 +57,7 @@ Description values containing spaces should be quoted in single quotes
+
For more details see
link:project-setup.html#submit_type[Change Submit Actions].
link:project-setup.html#submit_type[Submit Types].
--content-merge::
If enabled, Gerrit will try to perform a 3-way merge of text

View File

@ -422,13 +422,16 @@ By default this is set to false.
[[auth.gitBasicAuth]]auth.gitBasicAuth::
+
If true then Git over HTTP and HTTP/S traffic is authenticated using
standard BasicAuth and credentials validated against the randomly
generated HTTP password or against LDAP when it is configured as
Gerrit Web UI authentication method.
standard BasicAuth and the credentials are validated using the same
auth method as configured for the Gerrit Web UI.
+
This parameter only affects git over http traffic. If set to false
then Gerrit will authenticate through DIGEST authentication and
the randomly generated HTTP password in Gerrit DB.
This parameter affects git over HTTP traffic and access to the REST
API. If set to false then Gerrit will authenticate through DIGEST
authentication and the randomly generated HTTP password in the Gerrit
database.
+
When `auth.type` is `LDAP`, service users that only exist in the Gerrit
database are still authenticated by their HTTP passwords.
+
By default this is set to false.

View File

@ -4,6 +4,7 @@
. Getting started
.. link:intro-quick.html[A Quick Introduction to Gerrit]
.. link:intro-change-screen.html[A Quick Introduction to the New Change Screen]
.. link:intro-project-owner.html[Project Owner Guide]
.. link:http://source.android.com/submit-patches/workflow[Default Android Workflow] (external)
. Web
.. Registering a new Gerrit account

View File

@ -0,0 +1,287 @@
= Project Owner Guide
This is a Gerrit guide that is dedicated to project owners. It
explains the many possibilities that Gerrit provides to customize the
workflows for a project.
[[project-owner]]
== What is a project owner?
Being project owner means that you own a project in Gerrit.
Technically this is expressed by having the
link:access-control.html#category_owner[Owner] access right on
`refs/*` on that project. As project owner you have the permission to
edit the access control list and the project settings of the project.
It also means that you should get familiar with these settings so that
you can adapt them to the needs of your project.
Being project owner means being responsible for the administration of
a project. This requires having a deeper knowledge of Gerrit than the
average user. Normally per team there should be 2 to 3 persons, who
have a certain level of Git/Gerrit knowledge, assigned as project
owners. It normally doesn't make sense that everyone in a team is
project owner. For normal team members it is sufficient to be committer
or contributor.
[[access-rights]]
== Access Rights
As a project owner you can edit the access control list of your
project. This allows you to grant permissions on the project to
different groups.
Gerrit comes with a rich set of permissions which allow a very
fine-grained control over who can do what on a project. Access
control is one of the most powerful Gerrit features but it is also a
rather complex topic. This guide will only highlight the most
important aspects of access control, but the link:access-control.html[
Access Control] chapter explains all the details.
[[edit-access-rights]]
=== Editing Access Rights
To see the access rights of your project
- go to the Gerrit WebUI
- click on the `Projects` > `List` menu entry
- find your project in the project list and click on it
- click on the `Access` menu entry
By clicking on the `Edit` button the access rights become editable and
you may save any changes by clicking on the `Save Changes` button.
Optionally you can provide a `Commit Message` to explain the reasons
for changing the access rights.
The access rights are stored in the project's Git repository in a
special branch called `refs/meta/config`. On this branch there is a
`project.config` file which contains the access rights. More
information about this storage format can be found in the
link:config-project-config.html[Project Configuration File Format]
chapter. What is important to know is that by looking at the history
of the `project.config` file on the `refs/meta/config` branch you can
always see how the access rights were changed and by whom. If a good
commit message is provided you can also see from the history why the
access rights were modified.
If a Git browser such as GitWeb is configured for the Gerrit server you
can find a link to the history of the `project.config` file in the
WebUI. Otherwise you may inspect the history locally. If you have
cloned the repository you can do this by executing the following
commands:
====
$ git fetch origin refs/meta/config:config
$ git checkout config
$ git log project.config
====
Non project owners may still edit the access rights and propose the
modifications to the project owners by clicking on the `Save for
Review` button. This creates a new change with the access rights
modifications that can be approved by a project owner. The project
owners are automatically added as reviewer on this change so that they
get informed about it by email.
[[inheritance]]
=== Inheritance
Normally when a new project is created in Gerrit it already has some
access rights which are inherited from the parent projects.
Projects in Gerrit are organized hierarchically as a tree with the
`All-Projects' project as root from which all projects inherit. Each
project can have only a single parent project, multi-inheritance is
not supported.
Looking at the access rights of your project in the Gerrit WebUI, you
only see the access rights which are defined on that project. To see
the inherited access rights you must follow the link to the parent
project under `Rights Inherit From`.
Inherited access rights can be overwritten unless they are defined as
link:access-control.html#block[BLOCK rule]. BLOCK rules are used to
limit the possibilities of the project owners on the inheriting
projects. With this, global policies can be enforced on all projects.
Please note that Gerrit doesn't prevent you from assigning access
rights that contradict an inherited BLOCK rule, but these access rights
will simply have no effect.
If you are responsible for several projects which require the same
permissions, it makes sense to have a common parent for them and to
maintain the access rights on that common parent. Changing the parent
of a project is only allowed for Gerrit administrators. This means you
need to contact the administrator of your Gerrit server if you want to
reparent your project. One way to do this is to change the parent
project in the WebUI, save the modifications for review and get the
change approved and merged by a Gerrit administrator.
[[refs]]
=== References
Access rights in Gerrit are assigned on references (aka refs). Refs in
Git exist in different namespaces, e.g. all branches normally exist
under `refs/heads/` and all tags under `refs/tags/`. In addition there
are a number of link:access-control.html#references_special[special refs]
and link:access-control.html#references_magic[magic refs].
Access rights can be assigned on a concrete ref, e.g.
`refs/heads/master` but also on ref patterns and regular expressions
for ref names.
A ref pattern ends with `/*` and describes a complete ref name
namespace, e.g. access rights assigned on `refs/heads/*` apply to all
branches.
Regular expressions must start with `^`, e.g. access rights assigned
on `^refs/heads/rel-.*` would apply to all `rel-*` branches.
[[groups]]
=== Groups
Access rights are granted to groups. It is useful to know that Gerrit
maintains its own groups internally but also supports different external
group backends.
The Gerrit internal groups can be seen in the Gerrit WebUI by clicking
on the `Groups` > `List` menu entry. By clicking on a group you can
edit the group members (`Members` tab) and the group options
(`General` tab).
Gerrit internal groups contain users as members, but can also include
other groups, even external groups.
Every group is owned by an owner group. Only members of the owner
group can administrate the owned group (assign members, edit the group
options). A group can own itself; in this case members of the group
can, for example, add further members to the group. When you create new
groups for your project to assign access rights to committer or other
roles, make sure that they are owned by the project owner group.
An important setting on a group is the option
`Make group visible to all registered users.`, which defines whether
non-members can see who is member of the group.
New internal Gerrit groups can be created under `Groups` >
`Create New Group`. This menu is only available if you have the global
capability link:access-control.html#capability_createGroup[Create Group]
assigned.
Gerrit also has a set of special
link:access-control.html#system_groups[system groups] that you might
find useful.
External groups need to be prefixed when assigning access rights to
them, e.g. link:access-control.html#ldap_groups[LDAP group names] need
to be prefixed with `ldap/`.
If the link:https://gerrit-review.googlesource.com/#/admin/projects/plugins/singleusergroup[
singleusergroup] plugin is installed you can also directly assign
access rights to users, by prefixing the username with `user/` or the
user's account ID by `userid/`.
[[common-access-rights]]
=== Common Access Rights
Different roles in a project, such as developer (committer) or
contributor, need different access rights. Examples for which access
rights are typically assigned for which role are described in the
link:access-control.html#example_roles[Access Control] chapter.
[[code-review]]
=== Code Review
Gerrit's main functionality is code review, however using code review
is optional and you may decide to only use Gerrit as a Git server with
access control. Whether you allow only pushes for review or also
direct pushes depends on the project's access rights.
To push a commit for review it must be pushed to
link:access-control.html#refs_for[refs/for/<branch-name>]. This means
the link:access-control.html#category_push_review[Push] access right
must be assigned on `refs/for/<branch-name>`.
To allow direct pushes and bypass code review, the
link:access-control.html#category_push_direct[Push] access right is
required on `refs/heads/<branch-name>`.
By pushing for review you are not only enabling the review workflow,
but you can also get automatic verifications from a build server
before changes are merged. In addition you can benefit from Gerrit's
merge strategies that can automatically merge/rebase commits on server
side if necessary. You can control the merge strategy by configuring
the link:project-setup.html#submit_type[submit type] on the project.
If you bypass code review you always need to merge/rebase manually if
the tip of the destination branch has moved. Please keep this in mind
if you choose to not work with code review because you think it's
easier to avoid the additional complexity of the review workflow; it
might actually not be easier.
You may also enable link:user-upload.html#auto_merge[auto-merge on
push] to benefit from the automatic merge/rebase on server side while
pushing directly into the repository.
[[project-options]]
== Project Options
As project owner you can control several options on your project.
The different options are described in the
link:project-setup.html#project_options[Project Options] section.
To see the options of your project
- go to the Gerrit WebUI
- click on the `Projects` > `List` menu entry
- find your project in the project list and click on it
- click on the `General` menu entry
[[submit-type]]
=== Submit Type
An important decision for a project is the choice of the submit type
and the content merge setting (aka `Automatically resolve conflicts`).
The link:project-setup.html#submit_type[submit type] is the method
Gerrit uses to submit a change to the project. The submit type defines
what Gerrit should do on submit of a change if the destination branch
has moved while the change was in review. The
link:project-setup.html#content_merge[content merge] setting applies
if the same files have been modified concurrently and tells Gerrit
whether it should attempt a content merge for these files.
When choosing the submit type and the content merge setting one must
weigh development comfort against the safety of not breaking the
destination branch.
The most restrictive submit type is
link:project-setup.html#fast_forward_only[Fast Forward Only]. Using
this submit type means that after submitting one change all other open
changes for the same destination branch must be rebased manually. This
is quite burdensome and in practice only feasible for branches with
very few changes. On the other hand, if changes are verified before
submit, e.g. automatically by a CI integration, with this submit type,
you can be sure that the destination branch never gets broken.
Choosing link:project-setup.html#merge_if_necessary[Merge If Necessary]
as submit type makes the life for developers more comfortable,
especially if content merge is enabled. If this submit strategy is used
developers only need to rebase manually if the same files have been
modified concurrently or if the content merge on such a file fails. The
drawback with this submit type is that there is a risk of breaking
the destination branch, e.g. if one change moves a class into another
package and another change imports this class from the old location.
Experience shows that in practice `Merge If Necessary` with content
merge enabled works pretty well and breaking the destination branch
happens rarely. This is why this setting is recommended at least for
development branches. You likely want to start with
`Merge If Necessary` with content merge enabled and only switch to a
more restrictive policy if you are facing issues with the build and
test stability of the destination branches.
Please note that there are other submit types available; they are
described in the link:project-setup.html#submit_type[Submit Type]
section.
GERRIT
------
Part of link:index.html[Gerrit Code Review]
SEARCHBOX
---------

View File

@ -1,56 +1,60 @@
= Gerrit Code Review - Project Configuration
== Create Through SSH
== Project Creation
Creating a new repository over SSH is perhaps the easiest way to
configure a new project:
There are several ways to create a new project in Gerrit:
====
ssh -p 29418 review.example.com gerrit create-project --name new/project
====
- in the Web UI under 'Projects' > 'Create Project'
- via the link:rest-api-projects.html#create-project[Create Project]
REST endpoint
- via the link:cmd-create-project.html[create-project] SSH command
See link:cmd-create-project.html[gerrit create-project] for more
details.
To be able to create new projects the global capability
link:access-control.html#capability_createProject[Create Project] must
be granted.
In addition, projects can be created link:#manual_project_creation[
manually].
== Manual Creation
Projects may also be manually created.
=== Create Git Repository
Create a Git repository under gerrit.basePath:
[[manual_project_creation]]
=== Manual Project Creation
. Create a Git repository under `gerrit.basePath`:
+
====
git --git-dir=$base_path/new/project.git init
====
+
[TIP]
By tradition the repository directory name should have a `.git`
suffix.
+
To also make this repository available over the anonymous git://
protocol, don't forget to create a `git-daemon-export-ok` file:
+
====
touch $base_path/new/project.git/git-daemon-export-ok
====
=== Register Project
. Register Project
+
Either restart the server, or flush the `project_list` cache:
+
====
ssh -p 29418 localhost gerrit flush-caches --cache project_list
====
[[project_options]]
== Project Options
[[submit_type]]
== Change Submit Action
=== Submit Type
The method Gerrit uses to submit a change to a project can be
modified by any project owner through the project console, `Projects` >
`List` > my/project. The following methods are supported:
[[fast_forward_only]]
* Fast Forward Only
+
This method produces a strictly linear history. All merges must
@ -60,6 +64,7 @@ To submit a change, the change must be a strict superset of the
destination branch. That is, the change must already contain the
tip of the destination branch at submit time.
[[merge_if_necessary]]
* Merge If Necessary
+
This is the default for a new project.
@ -69,6 +74,7 @@ branch, then the branch is fast-forwarded to the change. If not,
then a merge commit is automatically created. This is identical
to the classical `git merge` behavior, or `git merge --ff`.
[[always_merge]]
* Always Merge
+
Always produce a merge commit, even if the change is a strict
@ -76,6 +82,7 @@ superset of the destination branch. This is identical to the
behavior of `git merge --no-ff`, and may be useful if the
project needs to follow submits with `git log --first-parent`.
[[cherry_pick]]
* Cherry Pick
+
Always cherry pick the patch set, ignoring the parent lineage
@ -105,9 +112,88 @@ When Gerrit tries to do a merge, by default the merge will only
succeed if there is no path conflict. A path conflict occurs when
the same file has also been changed on the other side of the merge.
[[content_merge]]
If `Automatically resolve conflicts` is enabled, Gerrit will try
to do a content merge when a path conflict occurs.
=== State
This setting defines the state of the project. A project can have the
following states:
- `Active`:
+
The project is active and users can see and modify the project according
to their access rights on the project.
- `Read Only`:
+
The project is read only and all modifying operations on it are
disabled. E.g. this means that pushing to this project fails for all
users even if they have push permissions assigned on it.
+
Setting a project to this state is an easy way to temporary close a
project, as you can keep all write access rights in place and they will
become active again as soon as the project state is set back to
`Active`.
+
This state also makes sense if a project was moved to another location.
In this case all new development should happen in the new project and
you want to prevent that somebody accidentally works on the old
project, while keeping the old project around for old references.
- `Hidden`:
+
The project is hidden and only visible to project owners. Other users
are not able to see the project even if they have read permissions
granted on the project.
=== Require Change-Id
The `Require Change-Id in commit message` option defines whether a
link:user-changeid.html[Change-Id] in the commit message is required
for pushing a commit for review. If this option is set, trying to push
a commit for review that doesn't contain a Change-Id in the commit
message fails with link:error-missing-changeid.html[missing Change-Id
in commit message footer].
It is recommended to set this option and use a
link:user-changeid.html#create[commit-msg hook] (or other client side
tooling like EGit) to automatically generate Change-Id's for new
commits. This way the Change-Id is automatically in place when changes
are reworked or rebased and uploading new patch sets gets easy.
If this option is not set, commits can be uploaded without a Change-Id,
but then users have to remember to copy the assigned Change-Id from the
change screen and insert it manually into the commit message when they
want to upload a second patch set.
=== Maximum Git Object Size Limit
This option defines the maximum allowed Git object size that
receive-pack will accept. If an object is larger than the given size
the pack-parsing will abort and the push operation will fail.
With this option users can be prevented from uploading commits that
contain files which are too large.
Normally the link:config-gerrit.html#receive.maxObjectSizeLimit[maximum
Git object size limit] is configured globally for a Gerrit server. At
the project level, the maximum Git object size limit can be further
reduced, but not extended. The displayed effective limit shows the
maximum Git object size limit that is actually used on the project.
The defined maximum Git object size limit is inherited by any child
project.
=== Require Signed-off-by
The `Require Signed-off-by in commit message` option defines whether a
link:user-signedoffby.html[Signed-off-by] line in the commit message is
required for pushing a commit. If this option is set, trying to push a
commit that doesn't contain a Signed-off-by line in the commit message
fails with link:error-not-signed-off-by.html[not Signed-off-by
author/committer/uploader in commit message footer].
== Registering Additional Branches

View File

@ -1086,7 +1086,7 @@ body as a link:#groups-input[GroupsInput] entity.
Content-Type: application/json;charset=UTF-8
{
"members": [
"groups": [
"MyGroup",
"MyOtherGroup"
]

View File

@ -78,4 +78,7 @@ public interface GerritResources extends ClientBundle {
@Source("listAdd.png")
public ImageResource listAdd();
@Source("dashboard.png")
public ImageResource dashboard();
}

View File

@ -185,6 +185,13 @@ public class ProjectInfoScreen extends ProjectScreen {
private void initProjectOptions() {
grid.addHeader(new SmallHeading(Util.C.headingProjectOptions()));
state = new ListBox();
for (ProjectState stateValue : ProjectState.values()) {
state.addItem(Util.toLongString(stateValue), stateValue.name());
}
saveEnabler.listenTo(state);
grid.add(Util.C.headingProjectState(), state);
submitType = new ListBox();
for (final SubmitType type : SubmitType.values()) {
submitType.addItem(Util.toLongString(type), type.name());
@ -198,13 +205,6 @@ public class ProjectInfoScreen extends ProjectScreen {
saveEnabler.listenTo(submitType);
grid.add(Util.C.headingProjectSubmitType(), submitType);
state = new ListBox();
for (final ProjectState stateValue : ProjectState.values()) {
state.addItem(Util.toLongString(stateValue), stateValue.name());
}
saveEnabler.listenTo(state);
grid.add(Util.C.headingProjectState(), state);
contentMerge = newInheritedBooleanBox();
saveEnabler.listenTo(contentMerge);
grid.add(Util.C.useContentMerge(), contentMerge);

View File

@ -139,6 +139,7 @@ public class ChangeScreen2 extends Screen {
@UiField InlineHyperlink ownerLink;
@UiField Element statusText;
@UiField Image projectSettings;
@UiField Image projectDashboard;
@UiField InlineHyperlink projectLink;
@UiField InlineHyperlink branchLink;
@UiField Element strategy;
@ -356,6 +357,13 @@ public class ChangeScreen2 extends Screen {
}
private void initProjectLinks(final ChangeInfo info) {
projectDashboard.addDomHandler(new ClickHandler() {
@Override
public void onClick(ClickEvent event) {
Gerrit.display(
PageLinks.toProjectDefaultDashboard(info.project_name_key()));
}
}, ClickEvent.getType());
projectSettings.addDomHandler(new ClickHandler() {
@Override
public void onClick(ClickEvent event) {
@ -365,7 +373,10 @@ public class ChangeScreen2 extends Screen {
}, ClickEvent.getType());
projectLink.setText(info.project());
projectLink.setTargetHistoryToken(
PageLinks.toProjectDefaultDashboard(info.project_name_key()));
PageLinks.toChangeQuery(
PageLinks.projectQuery(
info.project_name_key(),
info.status())));
}
private void initBranchLink(ChangeInfo info) {

View File

@ -166,6 +166,11 @@ limitations under the License.
cursor: pointer;
}
.projectDashboard {
float: right;
cursor: pointer;
}
.infoColumn {
width: 440px;
padding-left: 17px;
@ -390,7 +395,14 @@ limitations under the License.
ui:field='projectSettings'
resource='{ico.gear}'
styleName='{style.projectSettings}'
title='Go to project'>
title='Go to project settings'>
<ui:attribute name='title'/>
</g:Image>
<g:Image
ui:field='projectDashboard'
resource='{ico.dashboard}'
styleName='{style.projectDashboard}'
title='Go to project dashboard'>
<ui:attribute name='title'/>
</g:Image>
</td>

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 KiB

View File

@ -25,6 +25,7 @@ import com.google.gerrit.server.account.AccountManager;
import com.google.gerrit.server.account.AccountState;
import com.google.gerrit.server.account.AuthRequest;
import com.google.gerrit.server.account.AuthResult;
import com.google.gerrit.server.auth.NoSuchUserException;
import com.google.gerrit.server.config.AuthConfig;
import com.google.inject.Inject;
import com.google.inject.Provider;
@ -155,6 +156,18 @@ class ProjectBasicAuthFilter implements Filter {
ws.setAccessPathOk(AccessPath.GIT, true);
ws.setAccessPathOk(AccessPath.REST_API, true);
return true;
} catch (NoSuchUserException e) {
if (password.equals(who.getPassword(who.getUserName()))) {
WebSession ws = session.get();
ws.setUserAccountId(who.getAccount().getId());
ws.setAccessPathOk(AccessPath.GIT, true);
ws.setAccessPathOk(AccessPath.REST_API, true);
return true;
} else {
log.warn("Authentication failed for " + username, e);
rsp.sendError(SC_UNAUTHORIZED);
return false;
}
} catch (AccountException e) {
log.warn("Authentication failed for " + username, e);
rsp.sendError(SC_UNAUTHORIZED);

View File

@ -0,0 +1,26 @@
// Copyright (C) 2014 The Android Open Source Project
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package com.google.gerrit.server.auth;
import com.google.gerrit.server.account.AccountException;
/** The user does not exist on the authentication server */
public class NoSuchUserException extends AccountException {
private static final long serialVersionUID = 1L;
public NoSuchUserException(String username) {
super(String.format("No such user: %s", username));
}
}

View File

@ -20,6 +20,7 @@ import com.google.common.collect.ImmutableSet;
import com.google.gerrit.common.data.ParameterizedString;
import com.google.gerrit.reviewdb.client.AccountGroup;
import com.google.gerrit.server.account.AccountException;
import com.google.gerrit.server.auth.NoSuchUserException;
import com.google.gerrit.server.config.ConfigUtil;
import com.google.gerrit.server.config.GerritServerConfig;
import com.google.gerrit.util.ssl.BlindSSLSocketFactory;
@ -178,7 +179,7 @@ import javax.security.auth.login.LoginException;
switch (res.size()) {
case 0:
throw new AccountException("No such user:" + username);
throw new NoSuchUserException(username);
case 1:
return res.get(0);

View File

@ -0,0 +1,30 @@
//Copyright (C) 2014 The Android Open Source Project
//
//Licensed under the Apache License, Version 2.0 (the "License");
//you may not use this file except in compliance with the License.
//You may obtain a copy of the License at
//
//http://www.apache.org/licenses/LICENSE-2.0
//
//Unless required by applicable law or agreed to in writing, software
//distributed under the License is distributed on an "AS IS" BASIS,
//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//See the License for the specific language governing permissions and
//limitations under the License.
package com.google.gerrit.server.git;
/**
* Thrown in inserting change or patchset, e.g. OrmException or IOException.
*/
public class InsertException extends Exception {
private static final long serialVersionUID = 1L;
InsertException(final String msg) {
super(msg, null);
}
InsertException(final String msg, final Throwable why) {
super(msg, why);
}
}

View File

@ -245,14 +245,17 @@ public class ReceiveCommits {
}
}
private static final Function<Exception, OrmException> ORM_EXCEPTION =
new Function<Exception, OrmException>() {
private static final Function<Exception, InsertException> INSERT_EXCEPTION =
new Function<Exception, InsertException>() {
@Override
public OrmException apply(Exception input) {
public InsertException apply(Exception input) {
if (input instanceof OrmException) {
return (OrmException) input;
return new InsertException("ORM error", input);
}
return new OrmException("Error updating database", input);
if (input instanceof IOException) {
return new InsertException("IO error", input);
}
return new InsertException("Error inserting change/patchset", input);
}
};
@ -691,7 +694,7 @@ public class ReceiveCommits {
log.error(String.format(
"Cannot add patch set to %d of %s",
e.getKey().get(), project.getName()), err);
} catch (OrmException err) {
} catch (InsertException err) {
reject(replace.inputCommand, "internal server error");
log.error(String.format(
"Cannot add patch set to %d of %s",
@ -725,7 +728,7 @@ public class ReceiveCommits {
}
try {
List<CheckedFuture<?, OrmException>> futures = Lists.newArrayList();
List<CheckedFuture<?, InsertException>> futures = Lists.newArrayList();
for (ReplaceRequest replace : replaceByChange.values()) {
if (magicBranch != null && replace.inputCommand == magicBranch.cmd) {
futures.add(replace.insertPatchSet());
@ -736,12 +739,12 @@ public class ReceiveCommits {
futures.add(create.insertChange());
}
for (CheckedFuture<?, OrmException> f : futures) {
for (CheckedFuture<?, InsertException> f : futures) {
f.checkedGet();
}
magicBranch.cmd.setResult(OK);
} catch (OrmException err) {
log.error("Can't insert changes for " + project.getName(), err);
} catch (InsertException err) {
log.error("Can't insert change/patchset for " + project.getName(), err);
reject(magicBranch.cmd, "internal server error");
} catch (IOException err) {
log.error("Can't read commits for " + project.getName(), err);
@ -1545,7 +1548,7 @@ public class ReceiveCommits {
ins.getPatchSet().getRefName());
}
CheckedFuture<Void, OrmException> insertChange() throws IOException {
CheckedFuture<Void, InsertException> insertChange() throws IOException {
rp.getRevWalk().parseBody(commit);
final Thread caller = Thread.currentThread();
@ -1569,7 +1572,7 @@ public class ReceiveCommits {
return null;
}
}));
return Futures.makeChecked(future, ORM_EXCEPTION);
return Futures.makeChecked(future, INSERT_EXCEPTION);
}
private void insertChange(ReviewDb db) throws OrmException, IOException {
@ -1873,7 +1876,7 @@ public class ReceiveCommits {
return true;
}
CheckedFuture<PatchSet.Id, OrmException> insertPatchSet()
CheckedFuture<PatchSet.Id, InsertException> insertPatchSet()
throws IOException {
rp.getRevWalk().parseBody(newCommit);
@ -1900,7 +1903,7 @@ public class ReceiveCommits {
}
}
}));
return Futures.makeChecked(future, ORM_EXCEPTION);
return Futures.makeChecked(future, INSERT_EXCEPTION);
}
PatchSet.Id insertPatchSet(ReviewDb db) throws OrmException, IOException {
@ -2266,6 +2269,8 @@ public class ReceiveCommits {
codeReviewCommit, rw, repo, project, new ArrayList<Change>(),
new HashMap<Change.Id, CodeReviewCommit>());
subOp.update();
} catch (InsertException e) {
log.error("Can't insert patchset", e);
} catch (IOException e) {
log.error("Can't scan for changes to close", e);
} catch (OrmException e) {

View File

@ -4,6 +4,7 @@ CORE = [
'download-commands',
'replication',
'reviewnotes',
'singleusergroup'
]
# buck audit parses and resolves all deps even if not reachable

View File

@ -7,6 +7,7 @@ GWT_COMPILER_OPTS = [
]
GWT_PLUGIN_DEPS = [
'//gerrit-gwtui-common:client',
'//gerrit-plugin-gwtui:gwtui-api-lib',
'//lib/gwt:user',
]