| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
This reverts merge request !14148
|
| |\
| |
| |
| |
| |
| |
| | |
Rework how recent push events are retrieved
Closes #35990
See merge request !13995
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
| |
'35012-navigation-add-option-to-change-navigation-color-palette' into 'master'"
This reverts merge request !13619
|
| |\
| |
| |
| |
| |
| |
| | |
Removes default scope from sortable
Closes #23079
See merge request !13558
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| | |
Remove unused code
See merge request !13657
|
| | |
| |
| |
| | |
Its last usage has been removed at 87ffd67617.
|
| | |
| |
| |
| |
| |
| | |
Its last usage has been removed at https://gitlab.com/mehlah/gitlab-ce/commit/9df6f7bfad#e6ff2c1091173fd03646752d4e30891f66d33db3_46_48
The method can still be useful but should be renamed `authorized_projects_sorted_by_activity`
for better clarity.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Rollback changes made to signing_enabled.
Closes #37202
See merge request !13956
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| |/ / |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| | |
Whitelist or fix additional `Gitlab/PublicSend` cop violations
See merge request !13467
|
| | |
| |
| |
| |
| | |
An upcoming update to rubocop-gitlab-security added additional
violations.
|
| |\ \
| |/
|/|
| |
| | |
Remove `username` from `User#sanitize_attrs` callback
See merge request !13511
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This attribute is since validated against `DynamicPathValidator`, which
has strict requirements for the characters allowed, and should no longer
need to be sanitized in a callback before saving.
This has additional benefits in our test suite, where every creation of
a `User` record was calling `Sanitize.clean` on a username value that
was always clean, since we're the ones generating it.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The method User#projects_limit_left would run "personal_projects.count"
but such a query is not memoized. As a result multiple calls to
User#projects_limit_left would result in multiple COUNT(*) queries being
executed.
To work around this this commit adds User#personal_projects_count which
simply memoizes the result of the COUNT(*) in an instance variable.
|
| |
|
|
|
|
| |
The "events" table has a foreign key on "events.project_id" with a
cascading delete. As such it's impossible for an event to have a
non-existing project ID.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Fixes needed when GitLab sign-in is not enabled
See merge request !12491
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
When sign-in is disabled:
- skip password expiration checks
- prevent password reset requests
- don’t show Password tab in User Settings
- don’t allow login with username/password for Git over HTTP requests
- render 404 on requests to Profiles::PasswordsController
|
| |/
|
|
| |
Add spec tests for encoding
|
| | |
|
| |
|
|
|
| |
This cop has been renamed to ActiveRecordSerialize to match the way
"ActiveRecord" is usually written.
|
| |
|
|
|
|
|
|
| |
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
into 'master'
Allow the feature flags to be enabled/disabled with more granularity
Closes #34078
See merge request !12357
|
| | |
| |
| |
| |
| |
| | |
exclusive
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This allows to enable/disable a feature flag for a given user, or a
given Flipper group (must be declared statically in the `flipper.rb`
initializer beforehand).
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |/
|
|
| |
search list
|
