Notes call `#after_note_created` and `#after_note_destroyed` on their
noteable in callbacks, so the noteable can perform tasks particular to
them, like cache expiry.
This is in preparation of the EE-specific class
`DesignManagement::Design` clearing its `user_notes_count` cache when
its note are created or destroyed.
Refactoring Rspec behaviour testing of a counter caching service into a
shared example.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13353
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.
Closesgitlab-org/gitlab-ee#7080
`perform_enqueued_jobs` is a Sidekiq method.
Using this method violates the Dependency inversion principle[0].
This commit replaces `perform_enqueued_jobs` with ActiveJob's abstract
method `perform_enqueued_jobs` in specs.
[0]: https://en.wikipedia.org/wiki/Dependency_inversion_principle
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
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.
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.
Closesgitlab-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
GitLab Bot
Luke Duncalfe
Heinrich Lee Yu
Ezekiel Kigbo
Jasper Maes
Michael Kozono
Cindy Pallares
Thong Kuah
Oswaldo Ferreira
Imre Farkas
Rémy Coutable
Takuya Noguchi
Alexis Reigel
Roger Rüttimann
Valery Sizov
Robert Speicher
Stan Hu
Bob Van Landuyt
blackst0ne
Mark Chao
Douglas Barbosa Alexandre
Lin Jen-Shin
Zeger-Jan van de Weg
Nick Thomas
Douwe Maan
Yorick Peterse
Francisco Javier López
Brett Walker
Toon Claes
James Lopez
Gabriel Mazetto
Robert Speicher
Jarka Kadlecova
Paul Charlton