| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Adds Rubocop rule for line break after guard clause
Closes #18040
See merge request gitlab-org/gitlab-ce!15188
|
| | |
| |
| |
| | |
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
These dropdown options are used for creating and transfering projects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this MR there were two GitHub related importers:
* Github::Import: the main importer used for GitHub projects
* Gitlab::GithubImport: importer that's somewhat confusingly used for
importing Gitea projects (apparently they have a compatible API)
This MR renames the Gitea importer to Gitlab::LegacyGithubImport and
introduces a new GitHub importer in the Gitlab::GithubImport namespace.
This new GitHub importer uses Sidekiq for importing multiple resources
in parallel, though it also has the ability to import data sequentially
should this be necessary.
The new code is spread across the following directories:
* lib/gitlab/github_import: this directory contains most of the importer
code such as the classes used for importing resources.
* app/workers/gitlab/github_import: this directory contains the Sidekiq
workers, most of which simply use the code from the directory above.
* app/workers/concerns/gitlab/github_import: this directory provides a
few modules that are included in every GitHub importer worker.
== Stages
The import work is divided into separate stages, with each stage
importing a specific set of data. Stages will schedule the work that
needs to be performed, followed by scheduling a job for the
"AdvanceStageWorker" worker. This worker will periodically check if all
work is completed and schedule the next stage if this is the case. If
work is not yet completed this worker will reschedule itself.
Using this approach we don't have to block threads by calling `sleep()`,
as doing so for large projects could block the thread from doing any
work for many hours.
== Retrying Work
Workers will reschedule themselves whenever necessary. For example,
hitting the GitHub API's rate limit will result in jobs rescheduling
themselves. These jobs are not processed until the rate limit has been
reset.
== User Lookups
Part of the importing process involves looking up user details in the
GitHub API so we can map them to GitLab users. The old importer used
an in-memory cache, but this obviously doesn't work when the work is
spread across different threads.
The new importer uses a Redis cache and makes sure we only perform
API/database calls if absolutely necessary. Frequently used keys are
refreshed, and lookup misses are also cached; removing the need for
performing API/database calls if we know we don't have the data we're
looking for.
== Performance & Models
The new importer in various places uses raw INSERT statements (as
generated by `Gitlab::Database.bulk_insert`) instead of using Rails
models. This allows us to bypass any validations and callbacks,
drastically reducing the number of SQL queries and Gitaly RPC calls
necessary to import projects.
To ensure the code produces valid data the corresponding tests check if
the produced rows are valid according to the model validation rules.
|
| |
|
|
|
|
| |
By using SQL::Union we can return a proper ActiveRecord::Relation,
making it possible to select the columns we're interested in (instead of
all of them).
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
into 'master'
Make sure group and project creation is blocked for new users that are external by default
Closes #39664
See merge request gitlab-org/gitlab-ce!15212
|
| | |
| |
| |
| | |
external by default
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Create idea of read-only database
Closes #37534
See merge request gitlab-org/gitlab-ce!14688
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
digitalmoksha/gitlab-ce-feature/verify_secondary_emails
# Conflicts:
# app/controllers/admin/users_controller.rb
# app/controllers/confirmations_controller.rb
# app/controllers/profiles/emails_controller.rb
# app/models/user.rb
# app/services/emails/base_service.rb
# app/services/emails/destroy_service.rb
# app/views/devise/mailer/confirmation_instructions.html.haml
# lib/api/users.rb
# spec/services/emails/destroy_service_spec.rb
|
| | |\
| | |
| | |
| | |
| | | |
Improved file logging for authentication events
See merge request gitlab-org/gitlab-ce!9196
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
# This is the 1st commit message:
Add logging for all web authentication events
# This is the commit message #2:
Re-add underscore to after_inactive_sign_up_path_for
# This is the commit message #3:
Standardize on username=
# This is the commit message #4:
after_filter -> after_action, _resource -> resource
# This is the commit message #5:
Add two-factor login failures and account lockouts
# This is the commit message #6:
Move logging from two-factor concern to user model
# This is the commit message #7:
Add spaces around default parameter assignments
# This is the commit message #8:
Move logs out of user model
# This is the commit message #9:
Replace filtered_params with user_params
# This is the commit message #10:
Standardize case
# This is the commit message #1:
Fixes for username and AppLogger.info
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Attempt to link saml users to ldap by email
Closes #33493
See merge request gitlab-org/gitlab-ce!14216
|
| | | |/ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| | | |
|
| | |
| |
| |
| | |
and rubocop fixes
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
a reconfirmation
|
| | |
| |
| |
| | |
make sure it stays confirmed
|
| | | |
|
| |/ |
|
| |
|
| |
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
|
