| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
Fortunately, only specs needed to be fixed, so that's good!
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
'21983-member-add_user-doesn-t-detect-existing-members-that-have-requested-access' into 'master'
Resolve "`Member.add_user`doesn't detect existing members that have requested access"
## What does this MR do?
This merge request handle the case when an access requester is added to a group or project (via the members page or the API).
In `Member.add_user`, if an access requester already exists, we simply accept their request (and set the `created_by`, `access_level` and `expires_at` attributes if given).
## Are there points in the code the reviewer needs to double check?
I've taken the opportunity to cleanup the whole `{Group,Project}Member.add_user*` methods since it was quite a mess.
## What are the relevant issue numbers?
Closes #21983
See merge request !6393
|
|
Changes include:
- Ensure Member.add_user is not called directly when not necessary
- New GroupMember.add_users_to_group to have the same abstraction level as for Project
- Refactor Member.add_user to take a source instead of an array of members
- Fix Rubocop offenses
- Always use Project#add_user instead of project.team.add_user
- Factorize users addition as members in Member.add_users_to_source
- Make access_level a keyword argument in GroupMember.add_users_to_group and ProjectMember.add_users_to_projects
- Destroy any requester before adding them as a member
- Improve the way we handle access requesters in Member.add_user
Instead of removing the requester and creating a new member,
we now simply accepts their access request. This way, they will
receive a "access request granted" email.
- Fix error that was previously silently ignored
- Stop raising when access level is invalid in Member, let Rails validation do their work
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
database IDs
Fixes failed builds such as https://gitlab.com/gitlab-org/gitlab-ce/builds/3919501
|
|
|
|
|
|
Todos sorting dropdown
Implements #18135
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5691
|
|
|
|
Use just SQL to check is a user can admin_issue on a project
Using offset pagination instead pages to avoid a count query
Tradeoff
- we duplicate how we check admin_issue in a SQL relation in the Ability class
|
|
Use just SQL to check is a user can admin_issue on a project
Tradeoff
- we duplicate how we check admin_issue in a SQL relation in the Ability class
|
|
Follow-up 1003454c
|
|
Follow-up on 1003454c
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Before when you choose the way of `sort` instead it display the title correctly it was just apply the humanize helper in sort value.
E.g.
When you choose `Last updated` it should display the title `Last updated` instead of `Recently updated`. This fix makes this correctly displays the title.
Change the implementation of the `link_to` `filter_branches_path`
- Change the value of the `params[:sort]` in `link_to`. E.g. instead of using `'recently_updated'` is now using `sort_value_recently_updated`.
- Change the values of the case in the `branches_sorted_by` method for the values it receives in the `params[:sort]` that are: `nil`, `'name'`, `'updated_desc'`, `'updated_asc'`.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
same time and writes tests accordingly
changes schema.db
removes duplicate field inside CHANGELOG
fix db/schema
|
|
|
|
|
|
|
|
|
|
|
|
Before: we took the next milestone due across all projects in the
search and found issues whose milestone title matched that
one. Problems:
1. The milestone could be closed.
2. Different projects have milestones with different schedules.
3. Different projects have milestones with different titles.
4. Different projects can have milestones with different schedules, but
the _same_ title. That means we could show issues from a past
milestone, or one that's far in the future.
After: gather the ID of the next milestone on each project we're looking
at, and find issues with those milestone IDs. Problems:
1. For a lot of projects, this can return a lot of IDs.
2. The SQL query has to be different between Postgres and MySQL, because
MySQL is much more lenient with HAVING: as well as the columns
appearing in GROUP BY or in aggregate clauses, MySQL allows them to
appear in the SELECT list (un-aggregated).
|
|
- Don't do setup in spec bodies.
- Don't `describe` a symbol.
- Don't use 'should'.
|
|
This ensures that IssuableFinder returns a collection of unique issues,
even when filtering issues using multiple labels.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Prevent Groups to have smaller visibility than projects
Add default_group_visibility_level to configuration
Code improvements
|
|
|
|
|
|
|
|
These changes were added in GitLab EE commit
d39de0ea91b26b8840195e5674b92c353cc16661. The tests were a bit bugged
(they used a non existing group, thus not testing a crucial part) which
I only noticed when porting CE changes to EE.
|
|
|
|
This class now uses a UNION (when needed) instead of plucking tens of
thousands of project IDs into memory. The tests have also been
re-written to ensure all different use cases are tested properly
(assuming I didn't forget any cases).
The finder has also been broken up into 3 different finder classes:
* ContributedProjectsFinder: class for getting the projects a user
contributed to.
* PersonalProjectsFinder: class for getting the personal projects of a
user.
* ProjectsFinder: class for getting generic projects visible to a given
user.
Previously a lot of the logic of these finders was handled directly in
the users controller.
|
|
In the previous setup the GroupsFinder class had two distinct tasks:
1. Finding the projects user A could see
2. Finding the projects of user A that user B could see
Task two was actually handled outside of the GroupsFinder (in the
UsersController) by restricting the returned list of groups to those the
viewed user was a member of. Moving all this logic into a single finder
proved to be far too complex and confusing, hence there are now two
finders:
* GroupsFinder: for finding groups a user can see
* JoinedGroupsFinder: for finding groups that user A is a member of,
restricted to either public groups or groups user B can also see.
|
|
|
|
|
|
|
