| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We had similar code in a few places to redirect to the last page if
the given page number is out of range. This unifies the handling in a
new controller concern and adds usage of it in all snippet listings.
|
|
- Avoid N+1 queries for authors and comment counts
- Avoid an additional snippet existence query
|
|
Sorting preference functionality has been extracted
from `IssuableCollections` to a new `SortingPreference`
concern in order to reuse this functionality in projects
(and groups in the future).
|
|
This mistake seems to have always been there, but it only resulted in
errors on the `/explore*.json` since they were the one that _actually_
relied on the local variables.
|
|
|
|
|
|
This removes remaining N+1 queries
|
|
Enables frozen string for the following:
* app/controllers/dashboard/**/*.rb
* app/controllers/explore/**/*.rb
* app/controllers/google_api/**/*.rb
* app/controllers/groups/**/*.rb
* app/controllers/import/**/*.rb
* app/controllers/instance_statistics/**/*.rb
* app/controllers/ldap/**/*.rb
* app/controllers/oauth/**/*.rb
* app/controllers/profiles/**/*.rb
Partially addresses #47424.
|
|
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
|
|
|
|
|
This changes the pagination of the "Explore" pages so they use a simpler
pagination system that only shows "Prev" and "Next" buttons. This
removes the need for getting the total number of rows to display, a
process that can easily take up to 2 seconds when browsing through a
large list of projects.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/27390
|
|
|
|
Use GroupsFinder to find subgroups the user has access to
See merge request !2096
|
|
Refactor snippets finder & dont return internal snippets for external users
See merge request !2094
|
|
Extended ProjectFinder in order to handle the following options:
- current_user - which user use
- project_ids_relation: int[] - project ids to use
- params:
- trending: boolean
- non_public: boolean
- starred: boolean
- sort: string
- visibility_level: int
- tags: string[]
- personal: boolean
- search: string
- non_archived: boolean
GroupProjectsFinder now inherits from ProjectsFinder.
Changed the code in order to use the new available options.
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27044
|
|
This commit introduces a Sidekiq worker that precalculates the list of
trending projects on a daily basis. The resulting set is stored in a
database table that is then queried by Project.trending.
This setup means that Unicorn workers no longer _may_ have to calculate
the list of trending projects. Furthermore it supports filtering without
any complex caching mechanisms.
The data in the "trending_projects" table is inserted in the same order
as the project ranking. This means that getting the projects in the
correct order is simply a matter of:
SELECT projects.*
FROM projects
INNER JOIN trending_projects ON trending_projects.project_id = projects.id
ORDER BY trending_projects.id ASC;
Such a query will only take a few milliseconds at most (as measured on
GitLab.com), opposed to a few seconds for the query used for calculating
the project ranks.
The migration in this commit does not require downtime and takes care of
populating an initial list of trending projects.
|
|
== Public Projects
This finder class now _only_ returns public projects. Previously this
finder would also return private and internal projects. Including these
projects makes caching data much harder and less efficient. Meanwhile
including this data isn't very useful as very few users would be
interested in seeing projects they have access to as trending. That is,
the feature is more useful when you want to see what _other_ popular
projects there are.
== Caching
The data returned by TrendingProjectsFinder is now cached for a day
based on the number of months the data should be restricted to. The
cache is not flushed explicitly, instead it's rebuilt whenever it
expires.
== Timings
To measure the impact I changed the finder code to use the last 24
months instead of the last month. I then executed and measured 10
requests to the explore page. On the current "master" branch (commit
88fa5916ffa0aea491cd339272ed7437c3f52dc7) this would take an average of
2.43 seconds. Using the changes of this commit this was reduced to
around 1.7 seconds.
Fixes gitlab-org/gitlab-ce#22164
|
|
In Rails 4.2 and below, skipping callbacks (skip_before_action, skip_after_action, etc.) that use methods which do not exist will not throw any errors.
On the other hand, Rails 5 does. See https://github.com/rails/rails/pull/19029
After testing with Rails 5 I noticed there are some methods that don't actually exist (because they were renamed, usually), this fixes a few instances of those.
reject_blocked! was introduced in c9def945d4222eeb8026a0311495259bf99267a1, I can't find any references to reject_blocked ever existing.
|
|
# Conflicts:
# app/models/issue.rb
# app/views/projects/_home_panel.html.haml
# app/views/shared/projects/_project.html.haml
# db/schema.rb
# spec/models/project_spec.rb
|
|
|
|
|
