summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Set version to 2.14.14v2.14.14David Pursehouse2018-09-266-6/+6
| | | | Change-Id: I5e6ce63b23c72f3fc293940e94a00affed294e77
* Update jruby to 9.1.17 and asciidoctorj to v1.5.7Paladox none2018-09-261-4/+4
| | | | | | | | | | | | | | | | | | | | | | Since Bazel 0.16, the build is done with an embedded JRE using Java version 9. This causes "illegal reflective access operation" warnings during the documentation build, because the version of jruby (9.1.13) doesn't support Java 9. Support for Java 9 was added in jruby 9.1.14 [1]. The subsequent releases also include bug fixes (see [2], [3], [4]). Note that we don't upgrade to the latest (9.2.0). Also upgrade asciidoctorj to the latest release, 1.5.7. [1] http://jruby.org/2017/11/08/jruby-9-1-14-0.html [2] http://jruby.org/2017/12/07/jruby-9-1-15-0.html [3] http://jruby.org/2018/02/21/jruby-9-1-16-0.html [4] http://jruby.org/2018/04/23/jruby-9-1-17-0.html Bug: Issue 9766 Change-Id: I2f84612905761c4bdfddca807e92f54247ef6f6e
* Elasticsearch: Ensure request URI is always prefixed with "/"David Pursehouse2018-09-263-3/+3
| | | | | | | | | | When using Amazon's Elasticsearch service, requests fail with "400 Bad Request" if they are not prefixed with "/". Ensure that requests are always prefixed with "/". Bug: Issue 9761 Change-Id: If2a178e85143ba75d7f4f6b982739a9b3f2dc21c
* AbstractElasticIndex: Factor out more variants of {post,perform}RequestDavid Pursehouse2018-09-265-15/+33
| | | | | | | | | | | | Factor out more variants of these methods that eventually end up in the one that actually makes the call to the RestClient instance. This will allow to make any necessary adjustments to the URI or request parameters in a single place. At the same time, reorder the arguments to make the order consistent across methods. Change-Id: I3ced32e8df6cbd5a5f05f4d3241f84a7e7bebb10
* rest-api-projects: Fix "unterminated listing block" warningDavid Pursehouse2018-09-261-2/+0
| | | | Change-Id: Ifddb6d4b6aa615205e60a6dc13388ecf8de9b46e
* config-gerrit: Fix "invalid reference: database.h2.cachesize" warningDavid Pursehouse2018-09-261-1/+1
| | | | | | | | During the documentation build, a warning is emitted because the reference "database.h2.cachesize" does not exist. The actual name is "database.h2.cacheSize" with upper-case S. Change-Id: I6481e77a88a2b340197a1369f1aa25973df83417
* Bazel: Specify name for downloaded file to http_file starlark ruleDavid Ostrovsky2018-09-252-8/+2
| | | | | | | | | | | | | | | | | | | | | In I44ca2ecfea6 native http_file was replaced with Starlark rule. During this migration the original file name was lost and hard coded to file named "downloaded". The closure_js_library expects files with .js suffix as source files, so that we had to add an intermediate rename step to make it work gain. In context of this feature request: [1] downloaded_file_path was added to the http_file rule: [2] so that we can use it now and can remove the intermediate renaming step. The aformentioned fix was included in 0.17.1 and we already have that version as the minimum required Bazel version, so that we can clean that up now. [1] https://github.com/bazelbuild/bazel/issues/5633 [2] https://github.com/bazelbuild/bazel/pull/5647 Change-Id: Ia00e5d7b4eb9c18be808b290ac299e658ab33b9a
* Set version to 2.14.14-SNAPSHOTDavid Pursehouse2018-09-256-6/+6
| | | | Change-Id: I78c09f7f0c716ef215904b070c74aa400f9a4c96
* Set version to 2.14.13v2.14.13David Pursehouse2018-09-216-6/+6
| | | | Change-Id: Ie95734511999c482cd5af453d95e37fd2a490ed8
* ElasticContainer: Use Elasticsearch 5.6.12 for V5_6 testsDavid Pursehouse2018-09-201-1/+1
| | | | Change-Id: Icb85272a3c1d68700d7b251d643c8640a82adfb7
* Add link to security documentation for Elasticsearch 6.4David Pursehouse2018-09-201-0/+1
| | | | Change-Id: I08b931ab1dce43d52bb066613a0f23f86836a508
* Link to homepage for Elasticsearch compatibilityDavid Pursehouse2018-09-201-2/+2
| | | | Change-Id: Ib585fc309183d7edec753d1976ca51d0f9fe29e3
* GerritServer#initAndStart: Remove unnecessary instantiation of ConfigDavid Pursehouse2018-09-201-2/+0
| | | | Change-Id: Ia2cc08e17d06d81af4d69f3c1e6afb6fff890dfa
* Revert "Suppress "unlikely argument type" warnings for IdString"David Pursehouse2018-09-202-2/+0
| | | | | | | | | Change I9d79b9064 was backported to stable-2.14 and fixes these warnings, so we no longer need the suppressions. This reverts commit 89ab8f45874954f6a3b74b29aa8f42cc010f814a. Change-Id: Ie2e38c12e908809df104e7ebe74921ac9902e42d
* IdString: Don't compare equal to stringsDave Borowitz2018-09-193-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Object#equals is supposed to define an equivalence relation[1][2]. This includes the property of symmetry: a.equals(b) if and only if b.equals(a). The old implementation of IdString#equals was asymmetrical: it returned true when comparing to a String with the same urlencoded value, but of course String#equals will always return false when comparing to an IdString. Fix IdString#equals to only compare equal to other IdStrings. It's trivial and readable to fix the few usages in Gerrit core. Since this method is part of the extension API, it's possible (though personally I think highly unlikely) that plugins in the wild are depending upon the current behavior, similar to how core was. Breakages may be subtle, if for example callers were trying to look up Strings in a Map<IdString, V>. However, it's worth noting that the asymmetric behavior of equals meant that plugins were _already_ in for subtly confusing or broken behavior. At a minimum need to mention this behavior change in release notes. [1] https://en.wikipedia.org/wiki/Equivalence_relation [2] Effective Java, Item 8: "Obey the general contract when overriding equals" Change-Id: I9d79b90640ea095b71803185d581cda77b93964e (cherry picked from commit e24bb8be8df1084406d2900c4bd0a7b51bb811d1)
* Upgrade elasticsearch-rest-client to 6.4.1David Pursehouse2018-09-191-2/+2
| | | | Change-Id: I6ababa146a93fcd23481b5f3ce2d55dc4486cdf3
* Upgrade JGit to 4.7.4.201809180905-rDavid Pursehouse2018-09-191-6/+6
| | | | | | | | | | | | | | | | This release contains the following fixes since 4.7.3.201809090215-r: - Fix ObjectUploadListener#close - Fix error handling in FileLfsServlet - ObjectDownloadListener#onWritePossible: Make code spec compatible - ObjectDownloadListener: Return from onWritePossible when data is written - Fix IOException when LockToken#close fails - Fix NoSuchFileException during directory cleanup in RefDirectory - Externalize warning message in RefDirectory.delete() - Suppress warning for trying to delete non-empty directory Bug: Issue 9667 Change-Id: Icc0a72d4c0301593d13434911e9a41ede4b6071b
* ElasticContainer: Use Elasticsearch 6.4.1 for V6_4 testsDavid Pursehouse2018-09-191-1/+1
| | | | Change-Id: I9dec94b81079574da0c66bca2860e093f70be8f4
* AbstractDaemonTest: Don't delete common server path too earlyDave Borowitz2018-09-195-30/+50
| | | | | | | | | | | | | | | | | | | | | | | Chaining the TemporaryFolder with the custom TestRule results in the directory for the common server being deleted after the first test method, even though it might still be needed. This means a @UseLocalDisk class cannot have more than one method, or things break, including but not limited to the NRT reopen threads throwing exceptions due to the index files disappearing out from under them. We just got lucky that none of our local disk tests were actually affected by this. To make this work, we can't tie the lifetime of the TemporaryFolder to a single AbstractDaemonTest method invocation. Instead, create the tempdir within GerritServer#initAndStart, and allow callers to get it back out. We have to be a bit more careful about managing the lifetime of the tempdir since some GerritServers, particularly in StandaloneSiteTest, have a shorter lifetime than their tempdirs. Fortunately, TempFileUtil make this relatively easy. As a nice side effect, we can get rid of the hack of passing the tempdir in via a Gerrit config option. Change-Id: I80ac66a27bc990f2cef966c9b372c86ce277c471
* Fix toolchain definitions for bazel 0.17.1Dave Borowitz2018-09-181-37/+7
| | | | | | | | | | | | | | Without this change, building fails with: $ bazel build tools:error_prone_warnings_toolchain ERROR: /usr/local/google/home/dborowitz/nobackup/c/gerrit-upstream/gerrit/tools/BUILD:45:1: no such target '@bazel_tools//tools/jdk:platformclasspath.jar': target 'platformclasspath.jar' not declared in package 'tools/jdk' (did you mean 'platformclasspath8.jar'?) defined by /usr/local/google/home/dborowitz/.cache/bazel/_bazel_` This target was renamed in 0.17.1: https://bazel.googlesource.com/bazel/+/3987300d6651cf0e6e91b395696afac6913a7d66 https://bazel.googlesource.com/bazel/+/35eaec4caae64af9077e7e614edfa62a09c3b0c4/CHANGELOG.md#release-0_17_1-2018_09_14 Change-Id: Ib1ade4041ecf3839e2755c21858882dca9dd30cb
* Bazel: Bump baseline to 0.17.1David Ostrovsky2018-09-181-1/+1
| | | | | | | New Bazel version is using JDK 9 javac. That will allow us to target JDK 9 in Gerrit build. Change-Id: I86666a9fda21c55852c64373bca2131ef0572c72
* FormatUtil: Correctly fix the Math#round() error flagged by error-proneAlice Kober-Sotzek2018-09-141-20/+2
| | | | | | | | | | | | | | | | | The fix applied by I1c88102d4 got rid of the error-prone warning but missed to address the actual issue in that line of code. The intention of the original code was to compute a double/float percentage and mathematically round it to the next integer/long value. However, as (long * int / long) == long, the computed percentage was a long value, for which the floor operation was automatically applied. Hence, the round function was even meaningless. The correct fix is to use a double value in the operation so that the result is also of type double and preserves all fractions. By doing so, we also get rid of the error-prone warning, which only indirectly hinted at that error. Change-Id: Iea07a05281faf00b0b52cf25a2fd35ca25b069c5
* Merge "Add a change deleted event/listener" into stable-2.14David Pursehouse2018-09-1411-5/+197
|\
| * Add a change deleted event/listenerDavid Pursehouse2018-09-1411-5/+197
|/ | | | | | | | | | | | | The new event is emitted on deletion of a draft change, and deletion of a regular change. Plugins may implement the ChangeDeletedListener to perform specific actions on change deletion. The event is included in the output of the stream-events ssh command. Bug: Issue 9711 Change-Id: I37424eafa73703f51072ff8ae6c2546a10ed5c7d
* Fix broken link in documentation of receive.requireSignedPushDavid Pursehouse2018-09-141-3/+4
| | | | Change-Id: Ic68c66d06c615626a6b3561fbd99fb88272a726a
* license-map: Fix deprecation warningDavid Pursehouse2018-09-121-1/+1
| | | | | | | DeprecationWarning: This method will be removed in future versions. Use 'list(elem)' or iteration over elem instead. Change-Id: Ib4733f8f6200408b06cb014358e5610dfbbc4f11
* Bazel: Make 'DefaultCharset' an ERROR when compiling with ErrorProne toolchainDavid Pursehouse2018-09-121-1/+1
| | | | Change-Id: I6cc3b0323731a0ff4aa2d743938742ecc3900c74
* Specify charset when constructing PrintWriterDavid Pursehouse2018-09-124-7/+12
| | | | Change-Id: I79170cbcbc573b037542a439592ca8de063fbd47
* Bazel: Change deprecated single file attribute parameterDavid Ostrovsky2018-09-111-1/+1
| | | | | | | | | single_file attribute is deprecated: [1] and should be replaced with allow_single_file. [1] https://docs.bazel.build/versions/master/skylark/lib/attr.html#parameters-3 Change-Id: I72f955ac47764c4eeb1ad65ab1f4b27db590521f
* Bazel: Remove deprecated FileTypeDavid Ostrovsky2018-09-112-2/+2
| | | | | | | | FileType is deprecated: [1] and should be replaced with list of strings. [1] https://docs.bazel.build/versions/master/skylark/lib/FileType.html Change-Id: Ifd9b9ac4ad35ae70aaf7ffc4e358792c80f12486
* Bazel: Replace PACKAGE_NAME constant with package_name() functionDavid Ostrovsky2018-09-112-2/+2
| | | | | | | | | | | PACKAGE_NAME was deprecated in favor of package_name() function and is going to be removed in future Bazel releases. Moreover Bazel is trying to set --incompatible_package_name_is_a_function=true per default to enforce Bazel users to stop using it: [1]. [1] https://github.com/bazelbuild/bazel/issues/5827 Change-Id: I4d1a6ccbeae611fdd0e9c1e9fdd89b6dd1294f36
* Upgrade JGit to 4.7.3.201809090215-rDavid Pursehouse2018-09-101-6/+6
| | | | | | | | | | | This release includes the following fixes since 4.7.2.201807261330-r: - Fix atomic lock file creation on NFS - Fix handling of option core.supportsAtomicCreateNewFile - GC: Avoid logging errors when deleting non-empty folders - Fix GC run in foreground to not use executor Change-Id: I6862cd6c3bff5b07234d886f80fb42504dd1ca79
* Merge "ProjectTagsScreen: Base visibility on the create refs/tags/* ↵David Pursehouse2018-09-107-14/+58
|\ | | | | | | permission" into stable-2.14
| * ProjectTagsScreen: Base visibility on the create refs/tags/* permissionMarco Miller2018-09-077-14/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the Tags creation form fields were visible also if either refs/* or refs/head/* was allowed for Create Reference. This fix limits that visibility to a create refs/tags/* permission solely, as per current documentation anyway. isOwnerAnyRef() still also makes the panel visible, overriding potentially missing ref creation permissions. Create Annotated Tag is still also required for the user to be able to use the optional Annotation field. In this case, the created tag is no longer lightweight but becomes annotated. Both kinds of tags are still supported through such a single Tags creation panel or form, thus the need to allow both permissions even if aiming for annotated tags only. (Command line does not have that design limitation indeed.) Bug: Issue 9689 Change-Id: I7e3d11a62ad1e49575e6ef743138158efa831e6a
* | Set version to 2.14.13-SNAPSHOTDavid Pursehouse2018-09-106-6/+6
| | | | | | | | Change-Id: I94df398e74616ff9237dde9da4e8d8a88b50ed5e
* | Set version to 2.14.12v2.14.12David Pursehouse2018-09-076-6/+6
| | | | | | | | Change-Id: Ia7925987947465f38be5b5ca4ef7ead970226d57
* | Merge "Assume correct relative or absolute URL from Weblink provider" into ↵David Pursehouse2018-09-063-7/+16
|\ \ | | | | | | | | | stable-2.14
| * | Assume correct relative or absolute URL from Weblink providerSven Selberg2018-09-063-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I you have a change URL like: http://localhost:8080/c/test-project/+/688 Stepping back to parts "../../" will get you: http://localhost:8080/c/ Wich is _not_ the base url. Do not try to guess how URL is constructed but trust WebLink providers to provide an absolute or a relative URL. Provide correct relative url from Gitweb. Bug: Issue 5316 Change-Id: I7f404d470a8fe0f32ef94bb2c7b4c6a9ba68a2b8 (cherry picked from commit 69ab4a8569a690da7d6fc0c57e0a74c2d97ef6c0)
* | | [project.config] Allow to add commentLink entriesHector Oswaldo Caballero2018-09-072-1/+36
| | | | | | | | | | | | Change-Id: I2fd01cb6775a905d7e602d5415102b274bd98fd3
* | | ElasticVersionTest: Align tested versions w/ ElasticContainer last onesMarco Miller2018-09-061-3/+2
| |/ |/| | | | | Change-Id: Iafc734d5f3a7e5f4ce9508f93525fe8348dd3b30
* | AbstractSubmit: Remove redundant assertion about null IOExceptionDavid Pursehouse2018-09-061-1/+1
|/ | | | | | | | | | | The call to assertThat(e).isNull() causes ErrorProne to raise a warning that there is a missing call to fail(), because it thinks that the exception is expected. Instead of asserting on the IOException, rethrow it as the cause of a new ValidationException. Change-Id: I7dd681196f8d63eb6f2a0063b55aa94d0ec1d71f
* ListMailFilter: Fix operator precedence warning raised by ErrorProneDavid Pursehouse2018-09-061-1/+2
| | | | | | | | Add grouping parenthesis to make the operator precedence explicit. See http://errorprone.info/bugpattern/OperatorPrecedence Change-Id: Ica10d3e1494e9109883ef0c327015e423e91dd31
* ListProjects: Fix operator precedence warning raised by ErrorProneDavid Pursehouse2018-09-061-2/+2
| | | | | | | | Add grouping parenthesis to make the operator precedence explicit. See http://errorprone.info/bugpattern/OperatorPrecedence Change-Id: I8a0853f8fac05218e77e1a94ebff989380246d37
* ChangeBundle: Fix operator precedence warning raised by ErrorProneDavid Pursehouse2018-09-061-3/+4
| | | | | | | | Add grouping parentheses to make the operator precedence explicit. See http://errorprone.info/bugpattern/OperatorPrecedence Change-Id: Iaf80a165e640f19bcb95b579cd3aba45ad9b20ba
* Bazel: fix error_prone_warnings_toolchain ruleDavid Pursehouse2018-09-061-1/+1
| | | | | | | | | | An incorrect target name causes the build to fail with: no such target '@bazel_tools//tools/jdk:platformclasspath8.jar' Removing the '8' suffix fixes it. Change-Id: I915239a5e1ce6403d7b6760d895aa085f00a1b83
* Elastic{Index|ReindexIT} Remove tests for 6.2 and 6.3David Pursehouse2018-09-062-22/+2
| | | | | | | | | | We don't need to test these versions all the time, so remove the tests. Support for versions 6.2 and 6.3 is kept; if we need to check for regressions we can manually enable the tests again later. Change-Id: Ia15785ad9cc995b4672814dd346e02a6ee4026a0
* ElasticVersionTest#version6: Add missing test for V6_4David Pursehouse2018-09-061-0/+1
| | | | Change-Id: I4ca4f304cdff6d8275e60856b992ee32d9c61027
* Allow more email RFC accepted chars in usernameJacek Centkowski2018-09-053-4/+13
| | | | | | | | | | | | | | | | | | | | Issue: Gerrit allows to specify email like username (especially handy when one wants to maintain unique email addresses across the server). However as opposite to what is described in [1] it allows only: ._- characters from allowed set that contains !#$%&‘*+–/=?^_`.{|}~ Considering the fact that I was able to perform clone (over SSH and HTTP) push for review, review and submit with all those characters but / this patch proposes to extend username allowed chars to !#$%&‘*+–=?^_`.{|}~ when @ is used (we have email like username) but keeps original characters set a-zA-Z0-9 when one uses single character for username. [1] https://www.mailboxvalidator.com/resources/articles/acceptable-email-address-syntax-rfc/ Change-Id: Iabb82cea5be32a68fe1d9fc65a6ca08743063a3f Signed-off-by: Jacek Centkowski <jcentkowski@collab.net>
* Make inheritance of receive.maxObjectSizeLimit optionalDavid Pursehouse2018-09-055-10/+50
| | | | | | | | | | | | | | | | Change I5f8b333e9 made the receive.maxObjectSizeLimit setting inherited from the parent project. However this is a change in behavior that users might not expect, and could have unexpected results. Rather than making this new behavior the default, make it so that it must be explicitly enabled in the site config by setting a new value, receive.inheritProjectMaxObjectSizeLimit, to true. Default the value to false when not explicitly set, to maintain backward compatibility with the behavior before change I5f8b333e9. Bug: Issue 9528 Change-Id: I63a990a61f0428148a5d26f9cf539d7d419b21ae
* Allow to inherit receive.maxObjectSizeLimit from parent projectDavid Pursehouse2018-09-0512-50/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current implementation it is possible to set the limit per project in the project.config on refs/meta/config, and at global level in $site/etc/gerrit.config. The project setting may override the global setting if it is lower. Changing the global setting requires a server restart. A limitation of this implementation is that we cannot set the limit at a project level and have it inherited to its child projects; it is necessary to explicitly set the limit on each child project. This limitation causes a lot of extra work in the case where for example we have a project hierarchy like: |- All-Projects | -- Namespace-A | | | |-- Project-A | |-- Project-B . . .. . . .. | |-- Project-X | | -- Namespace-B Where the Namespace-X projects are assumed to be "parent only" projects, if we want to set a limit for all the projects under a namespace hierarchy, we need to set it explicitly on all those projects individually rather than only on the "Namespace-X". With this change the limit is inherited from the parent project. The global limit is still respected, and the project still can't set a higher value than the global, either explicitly per project or via inheritance. Similarly, if no global limit is specified, a child project still may not set a limit higher than its parent. The inheritedValue is removed from the config info and replaced by a summary string describing how the effective value was inherited or overridden from the parent project or the global config. This string is used as the tooltip on the effective value in the UI. As a side effect of this change, it is now possible to effectively change the global limit without having to restart the server, by setting it on the All-Projects project. Note that this only works if the new limit is lower than what is already configured in the actual global limit in gerrit.config. Bug: Issue 9528 Change-Id: I5f8b333e905ed0a147526ae33ff2bab2cbe222ef
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 05:13:54 +0000