| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 2c3c5b35549185080296670cfe6710aa80f99944.
Revisit this after https://gitlab.com/gitlab-org/gitlab-ce/issues/45441
|
|
Make archived projects completely read-only
Closes #44788
See merge request gitlab-org/gitlab-ce!18136
|
|
This prevents creating merge requests targeting archived projects.
This could happen when a project was already forked, but then the
source was archived.
|
|
This removes the extra check for project-ids which is not needed at all.
This does not necessarily reduce execution time of the query, but
improves planning time by a few millseconds.
Closes #37125.
|
|
|
|
|
|
|
|
These extra sort keys caused sequential scans on the namespaces and projects
page. Removing them makes the page load on GitLab.com.
Closes #44338
|
|
Closes #40525.
|
|
into 'master'
Add overview of branches and filtered views for active/stale branches
Closes #40187 et #17293
See merge request gitlab-org/gitlab-ce!15402
|
|
|
|
This was causing todo priority sorting to fail.
|
|
Resolve "API support for selecting only updated issues before/after a given date"
Closes #41616
See merge request gitlab-org/gitlab-ce!17417
|
|
|
|
|
|
Don't use ProjectsFinder in TodosFinder
Closes #43767
See merge request gitlab-org/gitlab-ce!17462
|
|
Revert Project.public_or_visible_to_user changes but apply change to SnippetsFinder
Closes #42877
See merge request gitlab-org/gitlab-ce!17476
|
|
|
|
Using ProjectsFinder in TodosFinder to limit todos to the right projects
leads to overly complicated and slow database queries. This commit
removes the use of ProjectsFinder in favour of using
Project.public_or_visible_to_current_user directly.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/43767
|
|
Because epic index page includes also epics from subgroups
it's necessary to also get descendant group labels for filtering.
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4773#note_61236542
|
|
|
|
This applies the changes introduced in `Project.public_or_visible_to_user`
to the snippets finder only.
We know that for `SnippetsFinder`, this change improves SQL timing from
5/23/25s to 0.7/2/4s (mean/p95/p99). At the same time, the scope was too
broad, (negatively) affecting SQL timings in various other places:
https://gitlab.com/gitlab-com/infrastructure/issues/3772
With this commit, the snippets dashboard stays usuable as we generally
don't run into statement timeouts. In contrast to the earlier change in
!17088, the scope of the change is limited to `SnippetsFinder` only,
thus not affecting other places.
|
|
These changes were introduced in MR
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17088. In
https://gitlab.com/gitlab-com/infrastructure/issues/3772 we discovered
these changes lead to a pretty drastic increase in SQL response timings.
We'll revert these changes so we can work on a better solution in the
mean time without GitLab.com (or other installations) experiecing
reduced performance in the mean time.
|
|
Add source and target branch filters to merge requests API
Closes #42492
See merge request gitlab-org/gitlab-ce!17355
|
|
|
|
service
|
|
Improve performance of searching for and auto completing of users
See merge request gitlab-org/gitlab-ce!17158
|
|
|
|
The frontend code doesn't use this so there's no practical point in
supporting this. We also hardcode the limit to 20 so users can no longer
request their own limit, which could overload the database (depending on
any upper bounds perhaps enforced by Kaminari).
|
|
We can instead just use a UNION. This removes the need for plucking
hundreds if not thousands of IDs into memory when a project has many
members.
|
|
|
|
Refactor IssuableFinder to extract model-specific logic
See merge request gitlab-org/gitlab-ce!17236
|
|
Simplify database queries in MembersFinder and improve performance for Projects::ProjectMembersController#index
Closes #41461
See merge request gitlab-org/gitlab-ce!17190
|
|
|
|
By extracting a new `filter_items` method, we can override that in the
IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
the model is the correct one, because we can just use the class we're in to know
that.
We can do the same for the VALID_PARAMS constant, by making it a class method.
|
|
This was the default behavior, because all members with `user_id` set to
`null` were excluded.
|
|
For each member being rendered on
Projects::ProjectMembersController#index, there was a query to the users
table to retrieve the corresponding user:
```
SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1
```
|
|
Realized window functions are not available in older MySQL versions
either.
Falling back to DISTINCT ON for postgresql and a convoluted translation
for MySQL.
|
|
|
|
Closes #41461.
|
|
Immediately using #from here requires a lot of changes in
other finders (e.g. IssuableFinder, TodosFinder). In all places where we
use #merge, this goes completely the wrong way when passed in a relation
that was built with `#from(...)`: The original query's FROM part gets
completely replaced.
This avoids changing all other places and focuses on improving
SnippetFinder with the downside of two (small) codepaths to do the same
thing.
|
|
|
|
|
|
|
|
Rather radical but avoids n+1 queries in the rather common case we want
to include information about the author.
|
|
'security-10-4-25223-snippets-finder-doesnt-obey-feature-visibility' into 'security-10-4'
[Port for security-10-4]: Makes SnippetFinder ensure feature visibility
|
|
Closes #40755.
|
|
|
|
Search query is especially slow if a user searches a generic string
which matches many records, in such case search can take tens of
seconds or time out. To speed up the search query, we search only for
first 1000 records, if there is >1000 matching records we just display
"1000+" instead of precise total count supposing that with such amount
the exact count is not so important for the user.
Because for issues even limited search was not fast enough, 2-phase
approach is used for issues: first we use simpler/faster query to get
all public issues, if this exceeds the limit, we just return the limit.
If the amount of matching results is lower than limit, we re-run more
complex search query (which includes also confidential issues).
Re-running the complex query should be fast enough in such case because the
amount of matching issues is lower than limit.
Because exact total_count is now limited, this patch also switches to
to "prev/next" pagination.
Related #40540
|
|
Otherwise we'd only preload the ancestors that would fit the
page. That way, when a search result was on the first page, but the
ancestor didn't fit the page anymore. We would not have the preloaded
ancestor when rendering the hierarchy.
|
