| Age | Commit message (Collapse) | Author |
|---|
|
Forbid the usage of reload
Closes #60218
See merge request gitlab-org/gitlab-ce!27125
|
|
The `#reload` makes to load all objects into memory,
and the main purpose of `#reload` is to drop the association cache.
The `#reset` seems to solve exactly that case.
|
|
|
|
|
|
Avoid checking Redis when User#last_activity_on is already up to date.
|
|
|
|
- we now use the hierarchy class also for epics
- also rename supports_nested_groups? into supports_nested_objects?
- move it to a concern
|
|
These can just be `delete` calls, with the caveat that it only takes one
argument.
|
|
This forks live at https://github.com/gitlabhq/default_value_for/tree/69-fix-action_controller-parameters-handling
and fixes an issue where default_value_for wouldn't handle
`ActionController::Parameters` correctly with Rails 5.
This fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/54093.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
|
|
|
|
|
Fix failing 500 errors when deploy tokens are used to clone
Closes gitlab-ee#7080
See merge request gitlab-org/gitlab-ce!20993
|
|
A DeployToken responds to `:username`, but it returns the username for the
token, not a User object. Don't attempt to log user activity in this case.
Closes gitlab-org/gitlab-ee#7080
|
|
The status is shown for
- The author of a commit when viewing a commit
- Notes on a commit (regular/diff)
- The user that triggered a pipeline when viewing a pipeline
- The author of a merge request when viewing a merge request
- The author of notes on a merge request (regular/diff)
- The author of an issue when viewing an issue
- The author of notes on an issue
- The author of a snippet when viewing a snippet
- The author of notes on a snippet
- A user's profile page
- The list of members of a group/user
|
|
This can be done trough the API for the current user, or on the
profile page.
|
|
|
|
Enable more frozen string in app/services/**/*.rb
See merge request gitlab-org/gitlab-ce!20702
|
|
Partially addresses #47424.
|
|
|
|
|
|
When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.
|
|
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4827 to CE
|
|
including/extending it
|
|
This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.
This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447
|
|
|
|
|
|
By caching the number of personal SSH keys we reduce the number of
queries necessary on pages such as ProjectsController#show (which can
end up querying this data multiple times).
The cache is refreshed/flushed whenever an SSH key is added, removed, or
when a user is removed.
|
|
|
|
It is possible for a fork not to have a source anymore, in this case
we don't need to keep track of the push event.
|
|
In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
secondary node). But in GitLab CE it also might be useful to have the
"read-only" idea around. So port it back to GitLab CE.
Also having the principle of read-only in GitLab CE would hopefully
lead to less errors introduced, doing write operations when there
aren't allowed for read-only calls.
Closes gitlab-org/gitlab-ce#37534.
|
|
|
|
|
|
|
|
|
|
|
|
Whenever you push to a branch GitLab will show a button to create a
merge request (should one not exist already). The underlying code to
display this data was quite inefficient. For example, it involved
multiple slow queries just to figure out what the most recent push event
was.
This commit changes the way this data is retrieved so it's much faster.
This is achieved by caching the ID of the last push event on every push,
which is then retrieved when loading certain pages. Database queries are
only executed if necessary and the cached data is removed automatically
once a merge request has been created, or 2 hours after being stored.
A trade-off of this approach is that we _only_ track the last event.
Previously if you were to push to branch A and B then create a merge
request for branch B we'd still show the widget for branch A. As of this
commit this is no longer the case, instead we will only show the widget
for the branch you pushed to most recently. Once a merge request exists
the widget is no longer displayed. Alternative solutions are either too
complex and/or too slow, hence the decision was made to settle for this
trade-off.
Performance Impact
------------------
In the best case scenario (= a user didn't push anything for more than 2
hours) we perform a single Redis GET per page. Should there be cached
data we will run a single (and lightweight) SQL query to get the
event data from the database. If a merge request already exists we will
run an additional DEL to remove the cache key.
The difference in response timings can vary a bit per project. On
GitLab.com the 99th percentile of time spent in User#recent_push hovers
between 100 milliseconds and 1 second, while the mean hovers around 50
milliseconds. With the changes in this MR the expected time spent in
User#recent_push is expected to be reduced down to just a few
milliseconds.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/35990
|
|
|
|
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.
To fix this:
1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
`Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
like that in several places.
3. Change the initializers to use that new form.
|
|
Closes #37073
|
|
|
|
|
|
|
|
|
|
|
|
|
