| 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.
|
|
Memoize Github::Shell's secret token
## What does this MR do?
`API::Helpers#secret_token` was reading the secret file on every invocation. This MR reads the file in the `gitlab_shell_secret_token.rb` initializer and saves it as a class variable at `Gitlab::Shell.secret_token`
## Are there points in the code the reviewer needs to double check?
- I'm not sure if the use of `cattr_accessor` is the best approach, or if should be moved into the `class << self` block?
- Should `API::Helpers#secret_token` be removed in favor of using `Gitlab::Shell.secret_token`?
## Why was this MR needed?
Performance optimization.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22510
See merge request !6599
|
|
This commit adds a number of _html columns and, with the exception of Note,
starts updating them whenever the content of their partner fields changes.
Note has a collision with the note_html attr_accessor; that will be fixed later
A background worker for clearing these cache columns is also introduced - use
`rake cache:clear` to set it off. You can clear the database or Redis caches
separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
respectively.
|
|
|
|
every request.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/22537
|
|
|
|
Initialize Redis pool in single-threaded context
See merge request !6613
|
|
This side-steps the need for mutexes and whatnot.
|
|
|
|
|
|
So we have a detailed view of what checks perform bad
|
|
Fix two problematic bits of code that will be deprecated or broken in Rails 5.
Found in the Rails 5 MR: !5555
These are safe to use in Rails 4.2.7 as well as Rails 5.0.0, so I figured I'd backport them for the sake of making that merge request smaller.
The explanation for the mime_types.rb code is here: https://github.com/rails-api/active_model_serializers/issues/1027#issuecomment-126543577
See merge request !6214
|
|
|
|
|
|
Security and safety improvements for gitlab-workhorse integration
Companion to https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/60
- Use a custom content type when sending data to gitlab-workhorse
- Verify (using JWT and a shared secret on disk) that internal API requests came from gitlab-workhorse
This will allow us to build features in gitlab-workhorse that require
more trust, and protect us against programming mistakes in the future.
This is designed so that no action is required for installations from
source. For omnibus-gitlab we need to add code that manages the shared
secret.
See merge request !5907
|
|
Old deployments of Gitlab might have a big number of old events to be
deleted. Such numbers cause the worker to timeout.
I've limited the amount of rows that should be destroyed at once to
10000, and increased how often pruning shall take place to 4 times a
day.
|
|
Since contribution calendar shows only 12 months of activity,
events older than that time are not visible anywhere and can be
safely pruned saving big amount of database storage.
Fixes #21164
|
|
|
|
|
|
Moves program tag into the global configuration since this doesn't
change and since Sidekiq workers get a unique context for each event.
Closes #21410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Password Credentials flow.
|
|
|
|
|
|
Because this method is a Rails scope we have to instrument it manually
as regular the instrumentation methods only instrument methods defined
directly on a Class or Module.
|
|
Remove Grack::Auth: part 2 (LFS)
Deprecate Grack::Auth and handle LFS in Rails controllers under the Project namespace.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/14501
See merge request !5369
|
|
Store OTP secret key in secrets.yml
## What does this MR do?
Migrate the value of `.secret` to `config/secrets.yml` if present, so that `.secret` can be rotated without preventing all users with 2FA from logging in. (On a clean setup, generate different keys for each.)
## Are there points in the code the reviewer needs to double check?
I'm not sure we actually need `.secret` at all after this, but it seems safer not to touch it.
## Why was this MR needed?
We have some DB encryption keys in `config/secrets.yml`, and one in `.secret`. They should all be in the same place.
## What are the relevant issue numbers?
#3963, which isn't closed until I make the relevant changes in Omnibus too.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- ~~API support 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 !5274
|
|
# Conflicts:
# lib/gitlab/redis.rb
|
|
remove-grack-lfs
|
|
Add the devise initializer config setting to enable the sending of notification
emails when a user changes their password.
|
|
|
|
We will trust redis configuration params loading to Gitlab::RedisConfig.
|
|
Fix Import/Export not working in HA mode
Use a shared path instead of `Tempfile` default `/tmp` so the import file is accessible by any GitLab instance.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20506
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [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 !5618
|
|
export worker
|
|
We do not want to proceed with loading the app in this case, as it could
lose a secret needed to decrypt values in the database.
|
|
|
|
This class does quite a few interesting things so let's instrument it so
we can see how much time is being spent in this class.
|
|
|
|
If an environment variable exists for secret_key_base, use that -
always. But don't save it to secrets.yml.
Also ensure that we never write to secrets.yml if there's a non-blank
value there.
|
|
Move the last secret from .secret to config/secrets.yml, and delete
.secret if it exists.
|
|
.secret stores the secret token used for both encrypting login cookies
and for encrypting stored OTP secrets. We can't rotate this, because
that would invalidate all existing OTP secrets.
If the secret token is present in the .secret file or an environment
variable, save it as otp_key_base in secrets.yml. Now .secret can be
rotated without invalidating OTP secrets.
If the secret token isn't present (initial setup), then just generate a
separate otp_key_base and save in secrets.yml.
Update the docs to reflect that secrets.yml needs to be retained past
upgrades, but .secret doesn't.
|
|
Since this isn't an ActiveRecord::Base descendant it wasn't
instrumented.
|
|
Closes #20452
|
