Merge branch 'stable-3.0' into stable-3.1 * stable-3.0: ElasticContainer: Upgrade V6_8 to elasticsearch 6.8.9 ElasticVersion: Replace unchecked throw w/ javadoc Remove obsolete parts from Java code style guide Elasticsearch: Remove support for EOL 6.5 version Fix edit diff url Change-Id: I8e44d38e1eeaf23c0c945ad52d58d1b3d32fe72e
diff --git a/Documentation/config-gerrit.txt b/Documentation/config-gerrit.txt index 0488085..b8b66ef 100644 --- a/Documentation/config-gerrit.txt +++ b/Documentation/config-gerrit.txt
@@ -3054,11 +3054,6 @@ For further information about Elasticsearch security, please refer to the documentation: -* link:https://www.elastic.co/guide/en/x-pack/5.6/security-getting-started.html[Elasticsearch 5.6] -* link:https://www.elastic.co/guide/en/x-pack/6.2/security-getting-started.html[Elasticsearch 6.2] -* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.3/security-getting-started.html[Elasticsearch 6.3] -* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.4/security-getting-started.html[Elasticsearch 6.4] -* link:https://www.elastic.co/guide/en/elastic-stack-overview/6.5/security-getting-started.html[Elasticsearch 6.5] * link:https://www.elastic.co/guide/en/elastic-stack-overview/6.6/security-getting-started.html[Elasticsearch 6.6] [[elasticsearch.username]]elasticsearch.username::
diff --git a/Documentation/dev-contributing.txt b/Documentation/dev-contributing.txt index d54c9fa..23ecd67 100644 --- a/Documentation/dev-contributing.txt +++ b/Documentation/dev-contributing.txt
@@ -1,10 +1,12 @@ +:linkattrs: = Gerrit Code Review - Contributing [[cla]] == Contributor License Agreement In order to contribute to Gerrit a link:dev-cla.html[Contributor -License Agreement] must be completed before contributions are accepted. +License Agreement,role=external,window=_blank] must be completed before +contributions are accepted. [[contribution-processes]] == Contribution Processes @@ -19,27 +21,28 @@ The lightweight contribution process has little overhead and is best suited for small contributions (documentation updates, bug fixes, small features). Contributions are pushed as changes and -link:dev-roles.html#maintainer[maintainers] review them adhoc. +link:dev-roles.html#maintainer[maintainers,role=external,window=_blank] +review them adhoc. For large/complex features, it is required to follow the link:#design-driven-contribution-process[design-driven contribution process] and specify the feature in a link:dev-design-docs.html[design -doc] before starting with the implementation. +doc,role=external,window=_blank] before starting with the implementation. -If link:dev-roles.html#contributor[contributors] choose the -lightweight contribution process and during the review it turns out +If link:dev-roles.html#contributor[contributors,role=external,window=_blank] +choose the lightweight contribution process and during the review it turns out that the feature is too large or complex, -link:dev-roles.html#maintainer[maintainers] can require to follow the -design-driven contribution process instead. +link:dev-roles.html#maintainer[maintainers,role=external,window=_blank] can +require to follow the design-driven contribution process instead. If you are in doubt which process is right for you, consult the -link:https://groups.google.com/d/forum/repo-discuss[repo-discuss] +link:https://groups.google.com/d/forum/repo-discuss[repo-discuss,role=external,window=_blank] mailing list. These contribution processes apply to everyone who contributes code to the Gerrit project, including link:dev-roles.html#maintainer[ -maintainers]. When reading this document, keep in mind that maintainers -are also contributors when they contribute code. +maintainers,role=external,window=_blank]. When reading this document, keep in +mind that maintainers are also contributors when they contribute code. If a new feature is large or complex, it is often difficult to find a maintainer who can take the time that is needed for a thorough review, @@ -56,7 +59,8 @@ |====================== | |Lightweight Contribution Process|Design-Driven Contribution Process |Overhead|low (write good commit message, address review comments)| -high (write link:dev-design-docs.html[design doc] and get it approved) +high (write link:dev-design-docs.html[design doc,role=external,window=_blank] +and get it approved) |Technical Guidance|by reviewer|during the design review and by reviewer/mentor |Review |adhoc (when reviewer is available)|by a dedicated mentor (if @@ -83,17 +87,17 @@ be reviewed before they will get submitted to the code base. To start your contribution, please make a git commit and upload it for review to the link:https://gerrit-review.googlesource.com/[ -gerrit-review.googlesource.com] Gerrit server. To help speed up the -review of your change, review these link:dev-crafting-changes.html[ -guidelines] before submitting your change. You can view the pending -Gerrit contributions and their statuses -link:https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit[here]. +gerrit-review.googlesource.com,role=external,window=_blank] Gerrit server. To +help speed up the review of your change, review these link:dev-crafting-changes.html[ +guidelines,role=external,window=_blank] before submitting your change. You can +view the pending Gerrit contributions and their statuses +link:https://gerrit-review.googlesource.com/#/q/status:open+project:gerrit[here,role=external,window=_blank]. Depending on the size of that list it might take a while for your change to get reviewed. Naturally there are fewer -link:dev-roles.html#maintainer[maintainers], that can approve changes, -than link:dev-roles.html#contributor[contributors]; so anything that -you can do to ensure that your contribution will undergo fewer +link:dev-roles.html#maintainer[maintainers,role=external,window=_blank], that +can approve changes, than link:dev-roles.html#contributor[contributors,role=external,window=_blank]; +so anything that you can do to ensure that your contribution will undergo fewer revisions will speed up the contribution process. This includes helping out reviewing other people's changes to relieve the load from the maintainers. Even if you are not familiar with Gerrit's internals, @@ -124,26 +128,28 @@ * think about possibilities how the feature could be evolved over time This is why for large/complex features it is required to describe the -feature in a link:dev-design-docs.html[design doc] and get it approved -by the link:dev-processes.html#steering-committee[steering committee], +feature in a link:dev-design-docs.html[design doc,role=external,window=_blank] +and get it approved by the +link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank], before starting the implementation. The design-driven contribution process has the following steps: -* A link:dev-roles.html#contributor[contributor] - link:dev-design-docs.html#propose[proposes] a new feature by - uploading a change with a link:dev-design-docs.html[design doc]. -* The design doc is link:dev-design-docs.html#review[reviewed] by - interested parties from the community. The design review is public +* A link:dev-roles.html#contributor[contributor,role=external,window=_blank] + link:dev-design-docs.html#propose[proposes,role=external,window=_blank] a new + feature by uploading a change with a + link:dev-design-docs.html[design doc,role=external,window=_blank]. +* The design doc is link:dev-design-docs.html#review[reviewed,role=external,window=_blank] + by interested parties from the community. The design review is public and everyone can comment and raise concerns. * Design docs should stay open for a minimum of 10 calendar days so that everyone has a fair chance to join the review. * Within 14 calendar days the contributor should hear back from the - link:dev-processes.html#steering-committee[steering committee] + link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank] whether the proposed feature is in scope of the project and if it can be accepted. * To be submitted, the design doc needs to be approved by the - link:dev-processes.html#steering-committee[steering committee]. + link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank]. * After the design was approved, the implementation is done by pushing changes for review, see link:#lightweight-contribution-process[ lightweight contribution process]. Changes that are associated with @@ -169,7 +175,7 @@ * Accepting the feature when it is implemented. * Supporting the feature by assigning a link:dev-roles.html#mentor[ - mentor] (if requested, see link:#mentorship[mentorship]). + mentor,role=external,window=_blank] (if requested, see link:#mentorship[mentorship]). If the implementation of a feature gets stuck and it's unclear whether the feature gets fully done, it should be discussed with the steering @@ -185,8 +191,8 @@ design review, feedback from various sides can be collected, which likely leads to improvements of the feature. * Once a design was approved by the - link:dev-processes.html#steering-committee[steering committee], the - contributor can be almost certain that the feature will be accepted. + link:dev-processes.html#steering-committee[steering committee,role=external,window=_blank], + the contributor can be almost certain that the feature will be accepted. Hence, there is only a low risk to invest into implementing a feature and see it being rejected later during the code review, as it can happen with the lightweight contribution process. @@ -197,12 +203,12 @@ [[mentorship]] == Mentorship -For features for which a link:dev-design-docs.html[design] has been -approved (see link:#design-driven-contribution-process[design-driven +For features for which a link:dev-design-docs.html[design,role=external,window=_blank] +has been approved (see link:#design-driven-contribution-process[design-driven contribution process]), contributors can gain the support of a mentor if they are committed to implement the feature. -A link:dev-roles.html#mentor[mentor] helps with: +A link:dev-roles.html#mentor[mentor,role=external,window=_blank] helps with: * doing timely reviews * providing technical guidance during code reviews @@ -212,12 +218,13 @@ A feature can have more than one mentor. To be able to deliver the promised support, at least one of the mentors must be a -link:dev-roles.html#maintainer[maintainer]. +link:dev-roles.html#maintainer[maintainer,role=external,window=_blank]. Mentors are assigned by the link:dev-processes.html#steering-committee[ -steering committee]. To gain a mentor, ask for a mentor in the -link:dev-design-docs.html#structure[Implementation Plan] section of the design -doc or ask the steering committee after the design has been approved. +steering committee,role=external,window=_blank]. To gain a mentor, ask for a +mentor in the link:dev-design-doc-template.html#implementation-plan[Implementation +Plan,role=external,window=_blank] section of the design doc or ask the steering +committee after the design has been approved. Mentors may not be available immediately. In this case, the steering committee should include the approved feature into the roadmap or
diff --git a/Documentation/dev-crafting-changes.txt b/Documentation/dev-crafting-changes.txt index c35350f..d101ffa 100644 --- a/Documentation/dev-crafting-changes.txt +++ b/Documentation/dev-crafting-changes.txt
@@ -107,7 +107,7 @@ change, so that reviewers will do it for you. Yes, the way to go is to extend gerrit CI to take care of this, but it's not yet implemented. -Gerrit generally follows the +Gerrit follows the link:https://google.github.io/styleguide/javaguide.html[Google Java Style Guide]. @@ -128,19 +128,6 @@ wrapper script. If you run your own copy, please use the same version, as there may be slight differences between versions. -When considering the style beyond just formatting rules, it is often -more important to match the style of the nearby code which you are -modifying than it is to match the style guide exactly. This is -especially true within the same file. - -Additionally, you will notice that most of the newline spacing -is fairly consistent throughout the code in Gerrit, it helps to -stick to the blank line conventions. Here are some specific -examples: - - * Keep a blank line between all class and method declarations. - * Do not add blank lines at the beginning or end of class/methods. - When to use `final` modifier and when not (in new code): Always:
diff --git a/java/com/google/gerrit/elasticsearch/ElasticVersion.java b/java/com/google/gerrit/elasticsearch/ElasticVersion.java index 82816fb..fb24cb0 100644 --- a/java/com/google/gerrit/elasticsearch/ElasticVersion.java +++ b/java/com/google/gerrit/elasticsearch/ElasticVersion.java
@@ -18,7 +18,6 @@ import java.util.regex.Pattern; public enum ElasticVersion { - V6_5("6.5.*"), V6_6("6.6.*"), V6_7("6.7.*"), V6_8("6.8.*"), @@ -48,7 +47,14 @@ } } - public static ElasticVersion forVersion(String version) throws UnsupportedVersion { + /** + * Convert a version String to an ElasticVersion if supported. + * + * @param version for which to return an ElasticVersion + * @return the corresponding ElasticVersion if supported + * @throws UnsupportedVersion + */ + public static ElasticVersion forVersion(String version) { for (ElasticVersion value : ElasticVersion.values()) { if (value.pattern.matcher(version).matches()) { return value;
diff --git a/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java b/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java index e4b45ed..df3ec5e 100644 --- a/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java +++ b/javatests/com/google/gerrit/elasticsearch/ElasticContainer.java
@@ -38,14 +38,12 @@ private static String getImageName(ElasticVersion version) { switch (version) { - case V6_5: - return "blacktop/elasticsearch:6.5.4"; case V6_6: return "blacktop/elasticsearch:6.6.2"; case V6_7: return "blacktop/elasticsearch:6.7.2"; case V6_8: - return "blacktop/elasticsearch:6.8.8"; + return "blacktop/elasticsearch:6.8.9"; case V7_0: return "blacktop/elasticsearch:7.0.1"; case V7_1:
diff --git a/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java b/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java index e36ff0b..280b884 100644 --- a/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java +++ b/javatests/com/google/gerrit/elasticsearch/ElasticVersionTest.java
@@ -22,9 +22,6 @@ public class ElasticVersionTest { @Test public void supportedVersion() throws Exception { - assertThat(ElasticVersion.forVersion("6.5.0")).isEqualTo(ElasticVersion.V6_5); - assertThat(ElasticVersion.forVersion("6.5.1")).isEqualTo(ElasticVersion.V6_5); - assertThat(ElasticVersion.forVersion("6.6.0")).isEqualTo(ElasticVersion.V6_6); assertThat(ElasticVersion.forVersion("6.6.1")).isEqualTo(ElasticVersion.V6_6); @@ -70,7 +67,6 @@ @Test public void atLeastMinorVersion() throws Exception { - assertThat(ElasticVersion.V6_5.isAtLeastMinorVersion(ElasticVersion.V6_7)).isFalse(); assertThat(ElasticVersion.V6_6.isAtLeastMinorVersion(ElasticVersion.V6_7)).isFalse(); assertThat(ElasticVersion.V6_7.isAtLeastMinorVersion(ElasticVersion.V6_7)).isTrue(); assertThat(ElasticVersion.V6_8.isAtLeastMinorVersion(ElasticVersion.V6_8)).isTrue(); @@ -85,7 +81,6 @@ @Test public void version6OrLater() throws Exception { - assertThat(ElasticVersion.V6_5.isV6OrLater()).isTrue(); assertThat(ElasticVersion.V6_6.isV6OrLater()).isTrue(); assertThat(ElasticVersion.V6_7.isV6OrLater()).isTrue(); assertThat(ElasticVersion.V6_8.isV6OrLater()).isTrue(); @@ -100,7 +95,6 @@ @Test public void version7OrLater() throws Exception { - assertThat(ElasticVersion.V6_5.isV7OrLater()).isFalse(); assertThat(ElasticVersion.V6_6.isV7OrLater()).isFalse(); assertThat(ElasticVersion.V6_7.isV7OrLater()).isFalse(); assertThat(ElasticVersion.V6_8.isV7OrLater()).isFalse();
diff --git a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js index bd0486f..142bd6a 100644 --- a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js +++ b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view.js
@@ -568,8 +568,7 @@ _goToEditFile() { // TODO(taoalpha): add a shortcut for editing - const editUrl = Gerrit.Nav.getEditUrlForDiff( - this._change, this._path, this._patchRange.patchNum); + const editUrl = Gerrit.Nav.getEditUrlForDiff(this._change, this._path); return Gerrit.Nav.navigateToRelativeUrl(editUrl); },
diff --git a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html index 9c59577..046a153 100644 --- a/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html +++ b/polygerrit-ui/app/elements/diff/gr-diff-view/gr-diff-view_test.html
@@ -394,6 +394,7 @@ }; element._change = { _number: 42, + project: 'gerrit', status: 'NEW', revisions: { a: {_number: 1, commit: {parents: []}}, @@ -407,6 +408,8 @@ assert.isTrue(!!editBtn); MockInteractions.tap(editBtn); assert.isTrue(redirectStub.called); + assert.isTrue(redirectStub.lastCall.calledWithExactly( + Gerrit.Nav.getEditUrlForDiff(element._change, element._path))); done(); }); });