summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'stable-2.16' into stable-3.0upstream/stable-3.0Luca Milanesio2022-11-180-0/+0
|\ | | | | | | | | | | | | | | | | * stable-2.16: Predicate: Add safety check against not(any()) Add an index-safe predicate that matches all changes Release-Notes: skip Change-Id: Ia64e074194cd561bc55a6f0e7976633aaa9bb2ff
| * Predicate: Add safety check against not(any())Dave Borowitz2022-11-182-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's tempting to use as a way to say "match no results", but it's very unsafe. This simple check won't catch all misuses, but it would have prevented Iad564dd47 from causing production problems. Fix one obvious caller that now trips this check. This was a real problem: a bare [is:watched] query on a large site for a user with no project watches required iterating all changes to return an empty result. We have real instances of this causing extremely long requests in our server logs. Release-Notes: skip Change-Id: Ib43f7466db5db315bf87558a37f18a1832ec641f (cherry picked from commit 02bab2161cd7ce7f682a28dad496a4465cb40844)
| * Add an index-safe predicate that matches all changesDave Borowitz2022-11-184-11/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Iad564dd47 was problematic in the error case because it returned Predicate.not(Predicate.any()). The "any" predicate is not an index predicate, which produces at least two problems: * When used in a with another non-index predicate, it might throw "no ChangeDataSource" from AndSource/OrSource. * More dangerously, when combined with an index predicate, it is used as a post-filtering predicate. A post-filtering predicate that matches no results means it gets applied to every change in the index before returning an empty set, which is bad. Instead, reuse a handy existing index predicate that is designed to return no results efficiently from the index: ChangeStatusPredicate.NONE. Expose this from a more general location, ChangeIndexPredicate#none(). Release-Notes: skip Change-Id: Ic9a7e277070cff7768ec91c1972cf8e9f6deacb1 (cherry picked from commit d9679cdb605b8a10977e1fc821f57dd5749b1dd5)
* | Merge branch 'stable-2.16' into stable-3.0Luca Milanesio2022-10-281-6/+15
|\| | | | | | | | | | | | | | | * stable-2.16: Cache repository locations in LocalDiskRepositoryManager Release-Notes: skip Change-Id: I39713079d081e7b80f59dc36e6181f4daa565c50
| * Cache repository locations in LocalDiskRepositoryManagerKaushik Lingarkar2022-10-281-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Obtaining the actual location of a repository using base-path and project name can be slow as it involves some guessing to locate the repository. Cache the locations once they are obtained to avoid repeated work, thereby improving performance when opening repositories. For example, on a site with 20k repositories on NFS, ls-projects with this change takes ~60s and ~90s without. Also, a query which wraps a large (~2k) list of manifest[1] operators will take ~300ms with this change and ~2s without it. [1] https://gerrit.googlesource.com/plugins/manifest Release-Notes: skip Change-Id: I8eab3c813c4ac9433e93c7ace96d38efe332be27
* | Merge branch 'stable-2.16' into stable-3.0Luca Milanesio2022-10-213-6/+58
|\| | | | | | | | | | | | | | | * stable-2.16: Limit the number of changes that can be submitted together Release-Notes: skip Change-Id: I263d636ec38f043ad5f6f8157ea5a57e12e7b145
| * Limit the number of changes that can be submitted togetherLuca Milanesio2022-10-183-6/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When chaining changes together, the sequence of commits to navigate was previously unbound, causing the potential explosion to millions of changes. The explosion could have also been accidental and caused by the push of a change with a non-existent branch, which would have resulted in the full scan of the repository for changes. Introduce a new Gerrit configuration change.maxSubmittableAtOnce with a safe default of 32767, which would allow any use case that would have also worked before this change. Navigating over 32767 changes up to potentially a huge number of commits would have generated a significant CPU and memory overload and still not resulted in a submittable chain of changes anyway. Release-Notes: Limit the number of changes that can be submitted at once Bug: Issue 16322 Change-Id: Id71aed2341f72708778395359bb6e4d4c270401c
* | Merge branch 'stable-2.16' into stable-3.0David Ostrovsky2022-06-283-12/+18
|\| | | | | | | | | | | | | | | | | | | | | * stable-2.16: Allow async receive-commits to have a thread-local cache Fix RepoRefCache stale checks during NoteDb rebuild Lazy load change notes when submit by push Change-Id: I52fd7c9320ce57488ab54f8b5b24a8eabb002ea5 Forward-Compatible: checked Release-Notes: skip
| * Allow async receive-commits to have a thread-local cacheLuca Milanesio2022-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | Git receive-commits are executed in a background thread of the ReceiveCommits pool. The thread-local cache allocated on the client caller thread isn't used in the execution of the command making multiple operations (e.g. ACL evaluation, events propagation) slower because of the missed caching activity. Release-Notes: Improve caching when merging changes through git push Change-Id: I34a6e1485294f3156c7f35261fedfc280af1ed43
| * Fix RepoRefCache stale checks during NoteDb rebuildLuca Milanesio2022-05-312-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rebuilding NoteDb meta-data from ReviewDb we are actually mutating the /meta ref during a reindexing operation. This is an edge case that happens only once during the on-line NoteDb upgrade and the trial mode. Adapt the RepoRefCache use during NoteDb reindexing and manage the situation where a staleness check applies to a ref that has disappeared on disk. Bug: Issue 15961 Release-Notes: skip Change-Id: Iac642eb7a9b24882a0c77dbaee24853fb0b29827
| * Lazy load change notes when submit by pushLuca Milanesio2022-05-301-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lazy load the change notes associated with the change to merge when one or more changes are submitted by a git push of the change onto its target branch. When a single change is merged through git push, we need to find which one is the corresponding change meta to be checked and merged. However, the building of the entire set of open changes against the target branch, indexed by their change key was having the side-effect of loading eagerly changes notes from their /meta ref. Loading all changes notes can be very slow, O(mins), on repositories with a large number of refs on slow storage and, also, it is completely unneeded in this use case. Loading all the change notes for all open changes had increased the time to submit a change from a few seconds (via the GUI) to a few minutes (via git push). Release-Notes: Performance improvement of change submit via push Change-Id: I646bc7b13f3359816b6be6354e15ddb5412bfa38
* | Merge branch 'stable-2.16' into stable-3.0Luca Milanesio2022-05-2021-244/+1142
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.16: Set PerThreadCache as readonly after creating a new patch-set Set PerThreadCache as readonly when formatting change e-mails Set PerThreadCache as readonly when formatting change JSON Set PerThreadCache as readonly after deleting a change Set PerThreadCache as readonly after abandoning a change Set PerThreadCache as readonly after merging a change Set PerThreadCache as readonly after posting review comments Introduce unloaders on PerThreadCache entries RepoRefCache: Hold a reference to the refDatabase with ref counting Remove use of RefCache in ChangeNotes Cache change /meta ref SHA1 for each change indexing task Also fix formatting of: java/com/google/gerrit/acceptance/GerritServer.java java/com/google/gerrit/server/mail/send/OutgoingEmail.java Release-Notes: skip Change-Id: I7fab22d2bfae52294b0f7d237a0d26b9fafa54d6
| * Set PerThreadCache as readonly after creating a new patch-setLuca Milanesio2022-04-292-14/+23
| | | | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the production of events after creating a new patch-set and for returning the merged change JSON response. The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta refs for new patch-sets Change-Id: I58abd12f3779e0a57c1f8cda618905c9c0bb9b7e
| * Set PerThreadCache as readonly when formatting change e-mailsLuca Milanesio2022-04-293-118/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the formatting the change e-mails body, which is done synchronously to the incoming REST API and thus impacts the latency perceived by the end user. The composition of the e-mail is using multiple information coming from multiple fields from NoteDb and calls the /meta refs lookups multiple times for the same change. The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta when producing JSON Change-Id: I993d4ddc37cf27b66ea9d7323963e761564603fa
| * Set PerThreadCache as readonly when formatting change JSONLuca Milanesio2022-04-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the formatting of change JSON output as return value for REST APIs. The ChangeJson class needs to read multiple fields from NoteDb and calls the /meta refs lookups multiple times for the same change JSON output (e.g. formatting the output JSON of an abandoned change generates 23 refs lookups calls for a single change). The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta when producing JSON Change-Id: Ic0e747352dcd8a0c2c1348a9878a5a4165777abd
| * Set PerThreadCache as readonly after deleting a changeLuca Milanesio2022-04-292-6/+16
| | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the production of events after deleting a change. The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta refs for deleted changes Change-Id: Ic04e9257b7801bd331390679e00e1f980a9d1d19
| * Set PerThreadCache as readonly after abandoning a changeLuca Milanesio2022-04-292-15/+24
| | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the production of events after abandoning a change. The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta refs for abandoned changes Change-Id: Iab71eca5ead78f6462fd3aaf41eb9590fce4684e
| * Set PerThreadCache as readonly after merging a changeLuca Milanesio2022-04-293-15/+28
| | | | | | | | | | | | | | | | | | | | | | | | Apply the same optimisation made for Change-Id: I1b71bfcf to the production of events after merging a change and for returning the merged change JSON response. The same considerations of performance improvement and reduction of /meta refs lookup are valid in this use-case. Release-Notes: enable the read-only cache of /meta refs for merged changes Change-Id: I34e147d644dfcdb5a6b1baa32cd4347805e506fc
| * Set PerThreadCache as readonly after posting review commentsLuca Milanesio2022-04-298-41/+468
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once the review comments mutations have been completed, it is safe to cache the results of the /meta refs lookups, avoiding the slowdown of the repeated refs lookups performed during the creation of the event with the added review and the dispatching of the stream event associated. The refs lookups could be as slow as 400 ms per lookup for a 500k refs repository on a shared NFS volume: using a thread-local cache for /meta ref lookup has a significant improvement (50% less refs lookups) on the overall user-experience. Introduce also the safety-net of checking for stale cached refs against the underlying repository, so that errors can arise during testing. The staleness checker can be enabled via system property. NOTE: The execution of the listeners logic associated with the review is left outside the read-only request window because of the risk of a plugin or hook updating the underlying /meta ref and causing a stale read. Also rename the current hasReadonlyRequest method to isReadonlyRequest, which is consistent with the new setter introduced in the PerThreadCache class. P.S. DO REVERT this change from stable-3.2 onwards because the refs lookups have been optimised already with the introduction of the cached-refdb libModule [1] which is enough to cover all use-cases introduced in the PerThreadCache for refs lookups. [1] https://gerrit.googlesource.com/modules/cached-refdb/ Bug: Issue 15798 Release-Notes: enable the read-only cache of /meta refs after review Change-Id: I1b71bfcff081e66eed897d41539d2be675f34af4
| * Introduce unloaders on PerThreadCache entriesLuca Milanesio2022-04-293-22/+131
| | | | | | | | | | | | | | | | | | | | | | | | RepoRefCache holds reference to a Repository object which would need once the cache entry is removed. Add the logic to cleanup the entry resource when the cache is closed and therefore entries need to be cleaned up before being removed from cache. Release-Notes: skip Change-Id: Id201d4a93792b27d2e1ab8214aa6377387eb567f
| * RepoRefCache: Hold a reference to the refDatabase with ref countingLuca Milanesio2022-04-285-4/+320
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RepoRefCache was holding a reference to a refDatabase associated to a Repository object that was created externally and could have been already closed once the RepoRefCache.get was called. Increment and decrement the reference counting for the Repository object held in the RepoRefCache, making sure that all accesses to the get() and other methods are always using an active and open repository. The problem existed for years but it was never noticed because of JGit being very flexible on using repositories even when their reference counting is zero and they are effectively closed. However, using a closed repository is inconsistent with its interface and may lead to further issues in the past, because of JGit not being aware of the repository is actually used by an in-memory cache holding a reference to it. Add one extra relevant tests associated with this corner case for showing the issue, using a TestRepositoryWithRefCounting wrapper that fails when accessing a refDatabase of a closed repository. Release-Notes: skip Change-Id: I4b2c43ea430a0506c73101bc4f6bc62926d5a094
| * Remove use of RefCache in ChangeNotesLuca Milanesio2022-04-253-19/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RefCache instance stored in the ChangeNotes refs field was passed as a nullable parameter but, effectively, always passed as null value in all invocations form the code-base. The refs field was also final, which means that it wasn't possible to memoize or cache any RefCache instance on it anyway. Remove the field and its use across the code-base, so that the code becomes easier to read and maintain. The cache was initially introduced in ChangeNotes with I5e02032d6 and used by the ChangeRebuilderImpl; however the implementation on how changes are rebuilt was changed with Icc942dba25 which did not require anymore the use of a RepoRefCache in ChangeNotes. However, Dave forgot to remove the refs from ChangeNotes which was left unused since then. Release-Notes: skip Change-Id: I729ad8738fd4ceebe72e61f086631f2d109a817a
| * Cache change /meta ref SHA1 for each change indexing taskLuca Milanesio2022-04-113-22/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Interactive indexing tasks of changes are executed synchronously with the incoming API: multiple lookups of change /meta ref name to SHA1 during the reindexing can compromise the performance of the API. The refs lookups could be as slow as 400 ms per lookup for a 500k refs repository on a shared NFS volume. Leverage the existing RepoRefCache associated with the PerThreadCache by creating a read-only cache during the execution of the indexing task. NOTE: The indexing task may be part of a mutable API (e.g. review a change); however, the operation itself is readonly because it is executed once the mutation has already happened and no further modifications to the change are done during the reindexing. Bug: Issue 15798 Release-Notes: cache the resolution of change /meta ref upon interactive indexing Change-Id: If137693293e3a6a5aa51babb5576690878d827d3
* | Merge branch 'stable-2.16' into stable-3.0Luca Milanesio2022-04-086-11/+90
|\| | | | | | | | | | | | | | | * stable-2.16: Cache change /meta ref SHA1 for each REST API request Release-Notes: skip Change-Id: I00882cba94ae51998ad0b34ab17b0fa4e2f4ecf5
| * Cache change /meta ref SHA1 for each REST API requestLuca Milanesio2022-04-086-12/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Gerrit REST APIs may cause multiple lookups of change /meta ref name to SHA1 during the same request, which could be as slow as 400 ms per lookup for a 500k refs repository on a shared NFS volume. Make sure that a lookup of a /meta ref happens only once per GET/HEAD API request by caching the result in a PerThreadCache scoped to the execution of the RestApiServlet. The measured improvement for a change reindex API (repo with 500k refs stored on an external NFS volume with trustfolderstat=false) is from 5s down to 500ms (10 times faster). For other APIs or local storage with trustfolderstat=true, the benefits are much more limited. NOTE: The improvement on all other APIs (PUT, POST, DELETE, PATCH) is outside the scope of this change, because it would imply a more complex eviction mechanism due to the mutation of the /meta ref during the potential NoteDb manipulation performed. Bug: Issue 15798 Release-Notes: cache the resolution of change /meta ref on REST API Change-Id: If41377b78cb0bbbde0fb22489a47f7634248e6f6
* | Merge branch 'stable-2.16' into stable-3.0Martin Fick2022-03-173-15/+21
|\| | | | | | | | | | | | | | | | | | | | | | | * stable-2.16: Revert "CmdLineParser: Remove unused prefix argument" Log the exception that caused the user's deactivation to fail Avoid re-reading refs in schema 161 Run background GC in Schema 144 and update GCs done in Schema 146 Trigger All-Users GC in background in schema 123 Release-Notes: skip Change-Id: I45dd6f9a2466881a3d7d9ebb0a6db5deb4b2eebe
| * Revert "CmdLineParser: Remove unused prefix argument"Martin Fick2022-03-171-3/+4
| | | | | | | | | | | | | | | | | | | | This reverts commit 8c380ffca36399fec35a84f13677efc751650a9a. Reason for revert: While the prefix argument defaults to "", it is needed to make use of the Options(prefix=) annotation. Release-Notes: skip Change-Id: I8941a127be47911dec6f7b99b7115489570058e1
| * Merge "Avoid re-reading refs in schema 161" into stable-2.16Nasser Grainawi2022-01-052-12/+17
| |\
| | * Avoid re-reading refs in schema 161Kaushik Lingarkar2021-12-202-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | A ref lookup using its name can be slow, especially in an unrepacked NFS based repository. Instead, use a Ref object which is already available to read labels. Change-Id: I31bafad54b7f69059235cc466d4a3d732ba44d97
| * | Log the exception that caused the user's deactivation to failLuca Milanesio2021-12-231-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | When failing to deactivate an account because of a resource conflict, the additional details of the exception helps the Gerrit admin to understand where the problem is coming from. The ResourceConflictException is typically triggered by the account being already inactive; however, it is also thrown in other points of the code and having the exception with the stack-trace helps troubleshooting deactivation issues. Change-Id: Idcb75f6c5b8fc63f6afb1f48bfe2f51a0c25188a
| * Run background GC in Schema 144 and update GCs done in Schema 146Kaushik Lingarkar2021-12-163-44/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial preparatory GC in schema 146 can be skipped for two reasons: 1) Several updates were done to keep All-Users in good state in preceding schemas by not writing loose objects. 2) Schema 144 now triggers a GC in the background. Schema 144 belongs to the same Gerrit release as 146, so users will never run an older version of 144(w/o the background GC) and a newer version of 146 (w/o the preparatory in-line GC). The inline GC in schema 146 which runs every 50 packs has been converted to a background GC. The intent of this inline GC was to keep All-Users from getting worse when there are a large number of user refs that need to be rewritten. Running a background GC also achieves that goal and has the added advantage of not holding up a data migration thread to run GC, thereby not slowing down the schema and allowing other schemas to proceed without waiting for the GC to complete. Change-Id: I16b048cf75671c40edc38e54d339735a93c1ebc9
| * Trigger All-Users GC in background in schema 123Kaushik Lingarkar2021-12-163-36/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New refs created under starred-changes using an atomic BatchRefUpdate operation leaves behind empty dirs in 'refs/starred-changes'. This can cause performance issues for subsequent schemas accessing these starred refs. A GC will clean up such empty ref dirs. Doing the GC inline will be a performance hit as the cleanup can be time-taking on NFS. Instead, run the GC in background at the end of this schema, which allows others schemas to then proceed without waiting for the GC to complete. Note that, the request to run GC in background will be ignored if another GC for that project is already queued. This change allows us to either remove the GCs done in Schema 146 or at the least run them in background. Change-Id: I1c9cb7cccfd87db7ffce57512562372af2fadff6
* | Merge branch 'stable-2.16' into stable-3.0Luca Milanesio2021-11-210-0/+0
|\| | | | | | | | | | | | | | | | | * stable-2.16: Set version to 2.16.29-SNAPSHOT Set version to 2.16.28 Use JGit 5.1.15.202012011955-r javadoc to resume release build Change-Id: I9830711780edf9140ef8cd3be2c995074de1df4d
| * Set version to 2.16.29-SNAPSHOTLuca Milanesio2021-11-196-6/+6
| | | | | | | | Change-Id: Iac867451c527cb6018ef963f530bbc80e33df915
| * Set version to 2.16.28v2.16.28Luca Milanesio2021-11-196-6/+6
| | | | | | | | Change-Id: I64e3a24286185db601fa73dca1f70dc87041bf5c
| * Use JGit 5.1.15.202012011955-r javadoc to resume release buildLuca Milanesio2021-11-181-1/+5
| | | | | | | | | | | | | | | | The javadoc site for 5.1.16 is not available anymore on the Eclipse's archive site: use the earlier version to resume the ability to release Gerrit. Change-Id: Ib1edf0cdefbed16a87a3187b33c0c4396a89e16f
* | Fix tests compilationOrgad Shaneh2021-11-161-2/+2
| | | | | | | | Change-Id: I629c741e9454af2fbc5dbf16a5da4ddbf42213ff
* | Merge branch 'stable-2.16' into stable-3.0Orgad Shaneh2021-11-154-3/+101
|\| | | | | | | | | | | | | | | | | | | | | * stable-2.16: VersionMetaData: Don't close passed in RevWalk AccessIT: Add tests for when group appears twice for same rule Prevent infinite loops with GWT UI and HTTP auth Change bouncycastle urls ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: Ie13fb6b21cf3478ecd9321bfc97c52f74416a4cf
| * VersionMetaData: Don't close passed in RevWalkOrgad Shaneh2021-11-151-1/+4
| | | | | | | | Change-Id: I36c6f470c624f82b517e93b11ec36e557b4cb456
| * AccessIT: Add tests for when group appears twice for same ruleNasser Grainawi2021-11-121-0/+89
| | | | | | | | | | | | | | A fix for this was added in Change Ia20714cc8 but that branch didn't have ITs in that area yet. Change-Id: I9fb72d14293a3ad55baa85aa69bf5adf65c5fb2e
| * Merge branch 'stable-2.15' into stable-2.16Nasser Grainawi2021-11-121-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | * stable-2.15: Change bouncycastle urls ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: I211ecf8b1c2d2b1929dc69826f63b2b9792a6697
| | * Merge branch 'stable-2.14' into stable-2.15upstream/stable-2.15Nasser Grainawi2021-11-121-1/+1
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.14: Change bouncycastle urls ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: I7d06e0e9217cfd2ead3b6378d37c703f60c9042a
| | | * Merge branch 'stable-2.13' into stable-2.14upstream/stable-2.14Nasser Grainawi2021-11-111-1/+1
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.13: Change bouncycastle urls ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: I5c5f4522d4297e3b98f880bdbdad519cf5dfb187
| | | | * Merge branch 'stable-2.12' into stable-2.13Nasser Grainawi2021-11-111-1/+1
| | | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.12: Change bouncycastle urls ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: Ibd331bef8541e965b582a12c58d061193497d858
| | | | | * Merge branch 'stable-2.11' into stable-2.12upstream/stable-2.12Nasser Grainawi2021-11-111-3/+3
| | | | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.11: Change bouncycastle urls Change-Id: I8acdc2efb0ee42d6722f637728886a283b914a2c
| | | | | | * Change bouncycastle urlsupstream/stable-2.11Adithya Chakilam2021-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old urls do not work and breaks the init command when run with in batch mode. Change-Id: Iad1dc772c729cad4bc410342b24a3dc89e6bd4dd
| | | | | * | Merge branch 'stable-2.11' into stable-2.12Nasser Grainawi2021-09-221-1/+1
| | | | | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.11: ListAccess: Fix incorrect behavior when group appears twice for same rule Change-Id: Ida30dac5678525b5eb15f80c1dc7a694d9f001bd
| | | | | | * ListAccess: Fix incorrect behavior when group appears twice for same ruleNasser Grainawi2021-08-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Later versions docs [1] have been updated to say that only a single rule is picked and that it is the first rule. That description matches the implementation for ACL evaluation in this version, but the REST API '/access/?project=<project>' returns the wrong value. [1] https://gerrit-review.googlesource.com/Documentation/access-control.html#_deny Change-Id: Ia20714cc8445b1f2d0c895fdc51ab72dc7ea0895 Bug: Issue 14963
| * | | | | | Prevent infinite loops with GWT UI and HTTP authLuca Milanesio2021-11-111-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The legacy HTTP form for switching to GWT UI from PolyGerrit UI did not take into account that the URL would have contained the '?polygerrit=0' query at the end, generating an invalid request '?polygerrit=0login/' and going into an infinite login loop '?polygerrit=0login/login/'. Detect the query string and build the redirection to the login preserving the query at the end of the constructed URL. Allow legacy GWT UI with HTTP authentication scheme, so that existing setups can smoothly migrate forward using v2.16 as an intermediate stop for using GWT and PolyGerrit UI together. Bug: Issue 15262 Change-Id: I934522e0024dc328df8a79035a820df4b7025dbc
* | | | | | | Merge branch 'stable-2.16' into stable-3.0Adithya Chakilam2021-11-101-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-2.16: Fix BatchMetaDataUpdate to not close passed in object reader Change-Id: I790dab96d7678d464f0bca2abff2bf256bf8dfdb
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 17:18:33 +0000