| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disable the "request access" functionality by default for new groups and projects
Currently this feature is enabled by default, and additional action is required to disable it.
Closes #21992
Closes !7011
See merge request !7425
|
| | |
| |
| |
| |
| | |
Set request access for projects/groups to false by default.
Request access implemented in !5286 8.10 was enabled by default.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Update 8.14-rc1 migrations to minimize downtime and deploy time
## What does this MR do?
Modify 8.14-rc1 migrations and code to minimize downtime and deploy time
## Are there points in the code the reviewer needs to double check?
No
## Why was this MR needed?
8.14-rc1 migrations took too much time in staging, so we didn't want to take too much downtime in production
## Does this MR meet the acceptance criteria?
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [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 it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #24386
See merge request !7427
|
| | | |
| | |
| | |
| | | |
See https://gitlab.com/gitlab-org/gitlab-ce/issues/24386
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Allow certain Sidekiq jobs to be throttled
## What does this MR do?
Allows certain slow running Sidekiq jobs to be throttled. It is disabled by default and can be enabled via the Application Settings.
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
## What are the relevant issue numbers?
Related to #23352
See merge request !7292
|
| | | |
| | |
| | |
| | | |
them to be configurable
|
| | |/ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
The AddVisibilityLevelToGroups migration introduced a visibility_level for
namespaces and specified that projects should always have a visibility level
less than or equal to their namespace. However, some invalid rows could have
been created.
This commit introduces a migration that updates the invalid rows, setting the
invalid project to have the same visibility_level as their namespaces. This
will make some projects internal or private when they would previously have
been public or internal, but this is better than silently making an internal
or private group public.
|
| |\
| |
| |
| |
| | |
Use separate email-friendly token for incoming email
See merge request !5914
|
| | |
| |
| |
| | |
reactivates all tests and writes more tests for it
|
| | |
| |
| |
| | |
email token be reset
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use more than one kind of Git garbage collection
Replaces https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6588 by @jacobvosmaer to get the builds to pass :)
Closes #22729
See merge request !7321
|
| | | | |
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
performance
We see that many slow queries on GitLab.com are dominated by finding
the project import data for a specific project. Adding an index is
the most straightforward way of fixing this.
Closes #23748
|
| |/
|
|
|
|
| |
are resolved
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
| |
round-robin between them
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use optimistic locking
## What does this MR do?
Removes the usage of pessimistic locking in favor of optimistic which is way cheaper and doesn't block database operation.
Since this is very simple change it should be safe. If we receive `StaleObjectError` message we will reload object a retry operations in lock.
However, I still believe that we need this one: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7005 as this will reduce a load on Database and FS.
This changes a behavior from:
### Pesimistic locking (previous behavior)
#### For updating
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. enqueue: (use: transition :created -> :pending)
5. [state_machine] we are in state created, we can go to pending
6. [state_machine] ci_pipeline.status = created
7. [state_machine] ci_pipeline.save
8. [state_machine] after_transition: (if for success): PipelineSuccessWorker on Sidekiq
9. release DB lock
#### If no update is required
1. SELECT * FOR UPDATE (other updates wait on this)
2. we update ci_pipeline
3. latest_build_status
4. we are in pending, we can't transition to pending, because it's forbidden
5. release DB lock
### Optimistic locking (implemented by this MR)
#### For updating
1. latest_build_status
2. enqueue: (use `transition :created -> :pending`)
3. [state_machine] we are in state created, we can go to pending
4. [state_machine] ci_pipeline.status = created
5. [state_machine] ci_pipeline.save
6. [state_machine] [save] where(lock_version: ci_pipeline.lock_version).update_all(status: :created, updated_at: Time.now)
7. [state_machine] [save] unless we_updated_row then raise ObjectInconsistentError
#### If no update is required
1. we update ci_pipeline
2. latest_build_status
3. we are in pending, we can't transition to pending, because it's forbidden
## Why was this MR needed?
We have been seeing a number of problems when we migrated Pipeline/Build processing to Sidekiq. Especially we started seeing a lot of blocking queries.
We used a pessimistic locking which doesn't seem to be required. This effectively allows us to fix our issues with blocked queries by using more efficient method of operation.
## What are the relevant issue numbers?
Issues: https://gitlab.com/gitlab-com/infrastructure/issues/623 and https://gitlab.com/gitlab-com/infrastructure/issues/584, but also there's a bunch of Merge Requests that try to improve behavior of scheduled jobs.
cc @pcarranza @yorickpeterse @stanhu
See merge request !7040
|
| | | |
|
| |/
|
|
| |
Code improvements, bug fixes, finish documentation and specs
|
| |
|
|
|
|
|
|
|
|
| |
mail_room was configured to deliver mail to the `incoming_email`
queue while `EmailReceiveWorker` was reading the `email_receiver`
queue. Adds a migration that repeats the work of a previous
migration to ensure all mails that wound up in the old
queue get processed.
Closes #23689
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
use separate renders
|
| |\ \
| |/ |
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/ |
|
| |
|
|
| |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | |
|
| |
|
|
|
| |
It seems this wasn't updated properly when migrations were added in a
previous commit.
|
| | |
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | |\
| | | |
| | | |
| | | |
| | | | |
Increase ci_builds artifacts_size column to 8-byte integer to allow larger files
See merge request !6333
|
| | | | | |
|
| | | |/
| | |
| | |
| | | |
Groups can enable/disable LFS, but this setting can be overridden at the project level. Admin only
|
| | |\ \
| | |/
| | |
| | |
| | | |
# Conflicts:
# db/schema.rb
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This moves tracking of the pushes since the last Git GC from PostgreSQL
to Redis. This reduces the number of writes on the "projects" table.
This in turn reduces the vacuuming overhead.
The lease used for incrementing the counter has been removed. This lease
was mostly put in place to prevent high database load but this isn't
needed anymore due to the counter now being stored in Redis.
Fixes gitlab-org/gitlab-ce#22125
|
