summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Set version to 3.2.8-SNAPSHOTupstream/stable-3.2-issue-13858David Ostrovsky2021-01-265-5/+5
| | | | Change-Id: Ic4fa85ad08771ef0b421c102b088adce45f42238
* Set version to 3.2.7v3.2.7David Ostrovsky2021-01-265-5/+5
| | | | Change-Id: I1f5706f2d4aa85b30be5660f623ce4b4fe3101ca
* Avoid creating HTTP Sessions for Git-over-HTTPLuca Milanesio2021-01-265-16/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Change-Id: Iffcd0fbd7 has involuntarily triggered the creation of a new HTTP Session for every invocation a Git-over-HTTP request. All came from the mistake of tracing the HTTP session instead of the Gerrit session in the audit record. The HTTP Servlet API specs say that any attempt to access the current session of an incoming request would result in the creation of a brand-new session. The session involuntarily created also had an expiry time equal to zero, which prevented the session housekeeper to reclaim them later on, even though they were unused. The consequence of creating an empty session for every Git-over-HTTP request isn't immediately tangible, because the session is empty and doesn't occupy a significant amount of memory. However, longer-term, the in-memory hashtable that records all the sessions, each one using 750 bytes on average, will be causing the overload of the JVM heap and the crash of the process because of lack of available memory. Use the correct Gerrit session-id, retrieving from the Provider<WebSession> the proper session, if active and logged in, and make sure in tests that no HTTP sessions are created as a result of a Git-over-http request. Bug: Issue 13858 Change-Id: I8c086fed54b196c3f46fa88ac78c127784524d30
* Merge branch 'stable-3.1' into stable-3.2David Ostrovsky2021-01-144-645/+3632
|\ | | | | | | | | | | | | | | | | * stable-3.1: Update git submodules AccountResolver: limit number of ambiguous accounts in error message Update highlightjs to 10.5.0 Change-Id: Ib49b3bb95a606db0d0418d9d2e467aadba330768
| * Merge "Update highlightjs to 10.5.0" into stable-3.1David Ostrovsky2021-01-142-642/+3624
| |\
| | * Update highlightjs to 10.5.0David Ostrovsky2021-01-112-642/+3624
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This upgrades currently used version 10.0.2 from May 2020. Build process is amended to use terser minification, as it provides better result as closure-compiler: [1] Terser (5.3.8): $ ls -all build/highlight.min.js -rw-r--r-- 1 davido users 977775 Jan 10 10:04 build/highlight.min.js Closure-Compiler (v20210106): $ ls -all build/highlight.min.js -rw-r--r-- 1 davido users 994034 Jan 9 12:10 build/highlight.min.js So, terser produces minified build that is 16259 bytes smaller. Moreover, in latest gerrit releases terser is also used for gr-app.js minification, so it appears to be consistent to also use terser for highlight.js minification. [1] https://github.com/highlightjs/highlight.js/issues/2956 Change-Id: I3a67dc05eb9c4fdac1bf578eacd777dfefb2a360
| * | Merge "AccountResolver: limit number of ambiguous accounts in error message" ↵Matthias Sohn2021-01-142-3/+8
| |\ \ | | | | | | | | | | | | into stable-3.1
| | * | AccountResolver: limit number of ambiguous accounts in error messageMatthias Sohn2021-01-132-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Don't list more than 3 ambiguous accounts in error message of UnresolvableAccountException in order to prevent flooding the log and displaying a lot of sensitive account data in an error dialog. Bug: Issue 13803 Change-Id: I95fe697988f3d900cce29ca93114a725b1c17ca6
| * | | Update git submodulesSven Selberg2021-01-141-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Update plugins/replication from branch 'stable-3.1' to 141f223240b15d3576f2d45525ed12b6ce7bc9bf - Document that authGroup must have Access Database Bug: Issue 13786 Change-Id: Iaf65252b25b9c40e5cfd1ac25d55fbf70536f83e
* | | | Update git submodulesSven Selberg2021-01-141-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Update plugins/replication from branch 'stable-3.2' to dedf422a7a0336096c5503d1f652f77873fbf11c - Merge branch 'stable-3.1' into stable-3.2 * stable-3.1: Document that authGroup must have Access Database Change-Id: I09378f4288fd1335932bdf120bba8418fc8f51c7 - Document that authGroup must have Access Database Bug: Issue 13786 Change-Id: Iaf65252b25b9c40e5cfd1ac25d55fbf70536f83e
* | | | Merge branch 'stable-3.1' into stable-3.2David Ostrovsky2021-01-133-9/+26
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-3.1: Update jetty version to 9.4.35.v20201120 Change-Id: I97edf8fb6c5f97df93aff2ef62b710cd08c780ef
| * | | Update jetty version to 9.4.35.v20201120David Ostrovsky2021-01-123-10/+27
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Includes a fix for CVE-2020-27218 [1] that affects versions prior to 9.4.35.v20201120. As of: [2] new dependency was added to jetty-servlet: jetty-util-ajax. [1] https://nvd.nist.gov/vuln/detail/CVE-2020-27218 [2] https://github.com/eclipse/jetty.project/issues/5539 Change-Id: I51549c9588f5748f36e145f8c4b347f97c08b4d8
* | | Add shadow-selection-polyfillDavid Ostrovsky2021-01-137-75/+532
| | | | | | | | | | | | | | | | | | | | | | | | This is a backport of change 293242 to stable-3.2 branch and to consume shadow-selection-polyfill module with npm. Bug: Issue 11811 Change-Id: Iaf62137e48b7d119be3d8be96ad03a7f316a5e69
* | | Merge branch 'stable-3.1' into stable-3.2David Ostrovsky2021-01-111-2/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change: 96ccc2388 Add shadow-selection-polyfill is reverted, as it will be migrated so that shadow-selection-polyfill dependency is consumed as npm module. * stable-3.1: Add shadow-selection-polyfill Update git submodules Revert "Upgrade soy to 2020-08-24" Change-Id: I0a863e9de9f35d4a9a77302e2a05d9850a2b3538
| * | Add shadow-selection-polyfillLuca Milanesio2021-01-114-4/+440
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The selection on shadow-DOM is not implemented in Safari and the document.getSelection() fallback is not suitable for use. The GoogleChromeLabs provided a library to solve the problem: shadow-selection-polyfill. What the library does is to manage the selection change events and calculate and cache the results for the shadow root elements, creating a custom event '-shadow-selectionchange' once the selection has been completed. There is one gotcha that makes things slightly more complicated: what the library provides is a Range and not a Selection object. There are a couple of adjustments needed in gr-diff and gr-diff-highlight to use the range directly instead of getting it from the selection. NOTE: Even though the shadow-selection-polyfill could also manage Chrome and Firefox, keep the existing logic to avoid any possible regression, which is not desireable on a stable branch. On stable-3.1, because of the problems related to the inclusion of the dependency via Bower, shadow.js has been removed from its exports and used as pure JS file included in the gr-diff.html. This change needs would not be applied to stable-3.2 where, thanks to the npm package mangement, it would be consumed from the NPM registry directly. Bug: Issue 11811 Change-Id: I41c4e94343010972c8a9f0f1ba3a059ca7af5292
| * Merge "Revert "Upgrade soy to 2020-08-24"" into stable-3.1David Ostrovsky2021-01-091-2/+2
| |\
| | * Revert "Upgrade soy to 2020-08-24"Matthias Sohn2020-12-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit bcdbc45e85efe98ea820f5024c5ca566ba0576d5. Han-Wen reported this soy version to show performance issues in Gerrit: "Google is tracking this internally as b/176094888; hopefully we can get it fixed in Soy proper. The problem is that template rendering went from 9ms to 30ms. We render quite a few templates for a single email, so adds ~120ms to each operation that sends out an email. It looks like this caused a significant slowdown on the benchmark under contrib/benchmark-createchange.go (using reftable as refstorage)." Hence reverting this update until it's fixed upstream. See https://gerrit-review.googlesource.com/c/gerrit/+/280196 Change-Id: Id98a5d93e316268e086cf6aa2be514a586dd3eee
| * | Update git submodulesAntonio Barone2021-01-071-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Update plugins/replication from branch 'stable-3.1' to 22ca0b406a4efb9aebbbfcac8d2d986812423f01 - Split integration tests to different targets Running all integration tests as part of one single 'replication_it' target does not cope well with the addition of extra tests, because it is bound to take longer and longer, eventually hitting any test timeout threshold. Splitting integration tests into different targets avoids timeout failures and also provides additional benefits, such as: - Better understanding of test failures - More efficient utilization of bazel build outputs and remote caching, effectively making tests execution faster. Bug: Issue 13909 Change-Id: Ifc6cce9996d3a8a23ec2a66c377978205fb6680f
* | | Merge "AliasConfig: Pass recursive=true into getNames() JGit methods" into ↵Nasser Grainawi2021-01-082-2/+2
|\ \ \ | | | | | | | | | | | | stable-3.2
| * | | AliasConfig: Pass recursive=true into getNames() JGit methodsNasser Grainawi2021-01-072-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This change solves the operator/operand aliasing not finding content in gerrit.config (it would only be found in secure.config). Change-Id: I10b96225526dc355e668357715f5e60a9d3d9751
* | | | Merge "Merge branch 'stable-3.1' into stable-3.2" into stable-3.2Saša Živkov2021-01-089-1/+642
|\ \ \ \ | |/ / / |/| | |
| * | | Merge branch 'stable-3.1' into stable-3.2Matthias Sohn2021-01-079-1/+642
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-3.1: Add script for incremental reindexing during upgrade Add query option allowing administrators to skip visibility filtering Change-Id: Iade61ce701a6efcbdcc12bf2a0dda6a9af32419e
| | * | Add script for incremental reindexing during upgradeMatthias Sohn2021-01-076-0/+529
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to shorten the downtime needed to reindex changes during a Gerrit upgrade the following strategy can be used: - index preparation - create a full consistent backup - note down the timestamp when the backup was created (backup-time) - create a complete copy of the production system from the backup - upgrade this copy to the new Gerrit version - online reindex this copy - upgrade of the production system - make system unavailable so that users can't reach it anymore e.g. by changing port numbers (downtime starts) - take a full backup - run $ ./reindex.py -u gerrit-url -s backup-time to write the list of changes which have been created or modified since the backup for the index preparation was created to a file "changes-to-reindex.list" - upgrade the production system to the new gerrit version skipping reindexing - copy the bulk of the new index from the copy system to the production system - run $ ./reindex.py -u gerrit-url this reindexes all changes which have been created or modified after the backup was taken reading these changes from the file "changes-to-reindex.list" - smoketest the system - make the production system available to the users again (downtime ends) Change-Id: Ie736e0dc32180329ca6ed31bcb49eb6b96bf2b91
| | * | Add query option allowing administrators to skip visibility filteringMatthias Sohn2021-01-053-1/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an administrator wants to reindex changes which were created or updated in a given period based on a query for that period the query results are subject to visibility filtering. This can have the effect that e.g. private changes are missed. Add a query option "skip-visibility" to allow administrators to skip visibility filtering. Change-Id: I66c13659587b9459eb7cc585697c1655926ceac3
* | | | Update git submodulesAntonio Barone2021-01-071-0/+0
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Update plugins/replication from branch 'stable-3.2' to 99c822ebf3b72023f8b926444bbdf299fafb00df - Merge branch 'stable-3.1' into stable-3.2 * stable-3.1: Split integration tests to different targets Don't check read permission when authgroup isn't set Change-Id: Ic5c8f0468869476a01923b4d374f0188c271daf2 - Split integration tests to different targets Running all integration tests as part of one single 'replication_it' target does not cope well with the addition of extra tests, because it is bound to take longer and longer, eventually hitting any test timeout threshold. Splitting integration tests into different targets avoids timeout failures and also provides additional benefits, such as: - Better understanding of test failures - More efficient utilization of bazel build outputs and remote caching, effectively making tests execution faster. Bug: Issue 13909 Change-Id: Ifc6cce9996d3a8a23ec2a66c377978205fb6680f - Don't check read permission when authgroup isn't set It's unnecessary to check read permission when authGroup isn't set since the then the user is a RemoteSiteUser that is-an InternalUser that has read access to everything. Change-Id: Ie6985250b0acb50c08fdcae75cc608222b1add35
* | | Merge branch 'stable-3.1' into stable-3.2Luca Milanesio2021-01-050-0/+0
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-3.1: Fix 'is:submittable' query on multiple submit records Update git submodules NOTE: No-op merge, the only commit needed was already cherry-picked onto stable-3.1 and the replication plugin should stay on its own stable-3.2 branch point. Change-Id: I18813f4cbb79ed900eeecef54a4cc676c6fba13b
| * | Fix 'is:submittable' query on multiple submit recordsLuke Alonso2020-12-312-6/+108
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a project has multiple submit rules, which produce multiple submit records, the 'is:submittable' query stops working as the documentation indicates it should. Rather than returning changes that are ready to be submitted, it returns any change where at least one submit record is OK, despite the overall change not being submittable. For example, with the code-owners plugin, which uses a java-based submit rule, 'is:submittable' will return changes that are passing owners checks, but might have CodeReview:-2 or Verified:-1. For projects with a single submit rule, the behavior is exactly the same as before, since we simply check that *any* of the submit records is OK, exactly as before, AND that *none* of them are NOT_READY or RULE_ERROR. Bug: Issue 13884 Change-Id: I4878ce13c6673852916d6891253d5e62b46f3db5
| * Update git submodulesSven Selberg2020-12-291-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | * Update plugins/replication from branch 'stable-3.1' to 0995fe0445f507279c05cb5ee60a9413671be400 - Don't check read permission when authgroup isn't set It's unnecessary to check read permission when authGroup isn't set since the then the user is a RemoteSiteUser that is-an InternalUser that has read access to everything. Change-Id: Ie6985250b0acb50c08fdcae75cc608222b1add35
* | Polygerrit: Wipe out license headers in minified gr-app.jsDavid Ostrovsky2021-01-051-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default terser keeps all licensing comments as many licenses require you to keep a copy of the license in redistributed source: [1] --comments [filter] Preserve copyright comments in the output. By default this works like Google Closure, keeping JSDoc-style comments that contain "@license" or "@preserve". You can optionally pass one of the following arguments to this flag: - "all" to keep all comments - `false` to omit comments in the output - a valid JS RegExp like `/foo/` or `/^!/` to keep only matching comments. Note that currently not *all* comments can be kept when compression is on, because of dead code removal or cascading statements into sequences. In minified gr-app.js version we don't need to preserve license information and can remove it. This saves ca. 300KB in gr-app.js size. [1] https://github.com/terser/terser Bug: Issue 13870 Change-Id: I2736879d252994200ad2f52e414e224ebe56b65d
* | Fix 'is:submittable' query on multiple submit recordsLuke Alonso2020-12-302-6/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a project has multiple submit rules, which produce multiple submit records, the 'is:submittable' query stops working as the documentation indicates it should. Rather than returning changes that are ready to be submitted, it returns any change where at least one submit record is OK, despite the overall change not being submittable. For example, with the code-owners plugin, which uses a java-based submit rule, 'is:submittable' will return changes that are passing owners checks, but might have CodeReview:-2 or Verified:-1. For projects with a single submit rule, the behavior is exactly the same as before, since we simply check that *any* of the submit records is OK, exactly as before, AND that *none* of them are NOT_READY or RULE_ERROR. Bug: Issue 13884 Change-Id: I4878ce13c6673852916d6891253d5e62b46f3db5
* | Set version to 3.2.7-SNAPSHOTLuca Milanesio2020-12-235-5/+5
| | | | | | | | Change-Id: Ida8557013073be101b5349458af1380b471ef59a
* | Set version to 3.2.6v3.2.6Luca Milanesio2020-12-235-5/+5
| | | | | | | | Change-Id: Ida9a38a340d6fc088b6350ed7cd42f9326b10374
* | Merge branch 'stable-3.1' into stable-3.2David Ostrovsky2020-12-2311-23/+11
|\| | | | | | | | | | | | | | | | | | | | | * stable-3.1: Set version to 3.1.12-SNAPSHOT Set version to 3.1.11 Fix httpcore dependency needed by httpclient Revert "Add support for Elasticsearch version 7.9.*" Revert "Add support for Elasticsearch version 7.10.*" Change-Id: I333a2434d66df525aa85687d9cc0134e7a398c21
| * Set version to 3.1.12-SNAPSHOTLuca Milanesio2020-12-235-5/+5
| | | | | | | | Change-Id: I4894bba96a34d5c5da8570d3d3a5bf04b77e70ee
| * Set version to 3.1.11v3.1.11Luca Milanesio2020-12-235-5/+5
| | | | | | | | Change-Id: I6c87be906a961c2b938d8260390ed4255fcd5102
| * Fix httpcore dependency needed by httpclientLuca Milanesio2020-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | httpcore has removed annotations used by httpclient and therefore it would fail to execute the annotation processor. E.g. the high-availability plugin, which uses the httpclient, won't compile anymore because is failing to find the missing annotation removed from httpcore from v4.4.5 onwards. The wrong httpcore dependency was introduced yesterday with the merge of Change-Id: I1fc91bce. Change-Id: I2d45001995806074534c11fc5230765e4c99e5a2
| * Revert "Add support for Elasticsearch version 7.9.*"Luca Milanesio2020-12-2310-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | Revert submission 291062 Reason for revert: requires an httpclient that Google cannot support Reverted Changes: I1fc91bce9:Align http dependencies with elasticsearch-rest-cl... Ifb941eea6:Add support for Elasticsearch version 7.10.* I7d76ece60:Add support for Elasticsearch version 7.9.* Change-Id: Ib95a8c053fa7f046596458e7eb719a409847cb82
| * Revert "Add support for Elasticsearch version 7.10.*"Luca Milanesio2020-12-2310-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | Revert submission 291062 Reason for revert: requires an httpclient that Google cannot support Reverted Changes: I1fc91bce9:Align http dependencies with elasticsearch-rest-cl... Ifb941eea6:Add support for Elasticsearch version 7.10.* I7d76ece60:Add support for Elasticsearch version 7.9.* Change-Id: I740e06058469a0ab12b14c7c616940bf429d0de7
* | Merge branch 'stable-3.1' into stable-3.2Sven Selberg2020-12-2117-17/+60
|\| | | | | | | | | | | | | | | | | | | | | * stable-3.1: ForRef#check should permit internal users to read all refs Add Jacek Centkowski to developers Add support for Elasticsearch version 7.10.* Add support for Elasticsearch version 7.9.* Align http dependencies with elasticsearch-rest-client Change-Id: Ia708f5a927da3f8ec8beef2470abfcf011843d5c
| * Merge "ForRef#check should permit internal users to read all refs" into ↵Sven Selberg2020-12-212-0/+14
| |\ | | | | | | | | | stable-3.1
| | * ForRef#check should permit internal users to read all refsSven Selberg2020-12-212-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 79d24d4 Make PermissionBackend#ForRef authoritative Introduced a regression where InternalUsers where not taken into consideration when checking READ permission. Bug: Issue 13786 Change-Id: I3f18507f65044ac96321c1efecf1f2688f36859f
| * | Merge changes Ifb941eea,I7d76ece6,I1fc91bce into stable-3.1Marco Miller2020-12-2111-17/+34
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | * changes: Add support for Elasticsearch version 7.10.* Add support for Elasticsearch version 7.9.* Align http dependencies with elasticsearch-rest-client
| | * | Add support for Elasticsearch version 7.10.*Marco Miller2020-12-1710-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrade elasticsearch-rest-client to 7.10.1. Add V7_10 to the version manager and use it for all the V7 tests. Change-Id: Ifb941eea63b90e107ae37c6a08ab1815d6c0f22b
| | * | Add support for Elasticsearch version 7.9.*Marco Miller2020-12-1710-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrade elasticsearch-rest-client to 7.9.3, which is the currently latest 7.9 minor version available. Add V7_9 to the version manager and use it for all the V7 tests. Change-Id: I7d76ece60d3ed7400bcf28bcd45d0e2e02870ccd
| | * | Align http dependencies with elasticsearch-rest-clientMarco Miller2020-12-172-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address the upstream issue [1] which is caused by the lack of upgrades done in this change. While waiting for Elastic to potentially provide shaded dependencies [1,2] for these, upgrade them herein still for now. Meaning, do not consider trying [2] this time around either. Favor the upgrade approach which is still simpler and likelier to succeed today. Base these new versions on [3]'s dependencies, even though the issue ([1]) didn't fail the build as such for version 7.8.1 of the client. This issue's fix starts becoming necessary from client versions 7.9.x, as shown by the follow-up upgrade change to 7.9.0 which requires this. The most downstream branch of gerrit to include this change determines from which Gerrit version the Elasticsearch versions 7.9.x can be supported. Set HTTPCOMP_VERS to the earlier 4.5.2, to comply with Google's currently deployed internal version. [1] https://github.com/elastic/elasticsearch/issues/61664 [2] https://www.elastic.co/guide/en/elasticsearch/client/java-rest/current/java-rest-low-usage-shading.html [3] https://search.maven.org/artifact/org.elasticsearch.client/elasticsearch-rest-client/7.8.1/jar Change-Id: I1fc91bce95d9e8094c19ad4044bd08b6285524af
| * | | Add Jacek Centkowski to developersMarco Miller2020-12-184-0/+12
| | | | | | | | | | | | | | | | Change-Id: If92e2efd75b8e8230f6ffc47f550a8cc92edea3b
* | | | Merge branch 'stable-3.1' into stable-3.2Marco Miller2020-12-181-7/+7
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-3.1: Upgrade testcontainers to 1.15.1 Change-Id: I38e8d0d4920fabbeb645c2e9dee8c7dd440f4b49
| * | | Merge "Upgrade testcontainers to 1.15.1" into stable-3.1Marco Miller2020-12-171-7/+7
| |\| |
| | * | Upgrade testcontainers to 1.15.1Marco Miller2020-12-171-7/+7
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to [1], "focuses on the stability and compatibility". Includes bug fixes and an update of docker-java to 3.2.7, which gets reflected in this change just as well. This change is currently necessary to successfully execute all the elastic core tests on macOS, with Docker Desktop, locally. [1] https://github.com/testcontainers/testcontainers-java/releases/tag/1.15.1 Change-Id: I9a7c443c69e3d054a6c52451b3aa3cf57a7933d3
* | | Merge branch 'stable-3.1' into stable-3.2David Ostrovsky2020-12-171-43/+25
|\| | | | | | | | | | | | | | | | | | | | * stable-3.1: SshDaemonIT: Perform some refactoring Change-Id: I4431413b86a1d574ecc7d799ba3289069a5cea7a
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 13:18:54 +0000