- 01 Feb, 2018 1 commit
-
-
Yorick Peterse authored
This ensures that we have more visibility in the number of SQL queries that are executed in web requests. The current threshold is hardcoded to 100 as we will rarely (maybe once or twice) change it. In production and development we use Sentry if enabled, in the test environment we raise an error. This feature is also only enabled in production/staging when running on GitLab.com as it's not very useful to other users.
-
- 31 Jan, 2018 2 commits
-
-
Takuya Noguchi authored
-
Stan Hu authored
We can simplify the code quite a bit and improve performance by using grape-entity merge fields: https://github.com/ruby-grape/grape-entity/tree/v0.6.0#merge-fields Relates to #42030
-
- 23 Jan, 2018 1 commit
-
-
Jan Provaznik authored
Search query is especially slow if a user searches a generic string which matches many records, in such case search can take tens of seconds or time out. To speed up the search query, we search only for first 1000 records, if there is >1000 matching records we just display "1000+" instead of precise total count supposing that with such amount the exact count is not so important for the user. Because for issues even limited search was not fast enough, 2-phase approach is used for issues: first we use simpler/faster query to get all public issues, if this exceeds the limit, we just return the limit. If the amount of matching results is lower than limit, we re-run more complex search query (which includes also confidential issues). Re-running the complex query should be fast enough in such case because the amount of matching issues is lower than limit. Because exact total_count is now limited, this patch also switches to to "prev/next" pagination. Related #40540
-
- 21 Jan, 2018 1 commit
-
-
Mark Fletcher authored
-
- 17 Jan, 2018 2 commits
-
-
Douwe Maan authored
[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project` See merge request gitlab/gitlabhq!2276 (cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c) 1f2bd3c0 Backport to 10.3
-
Stan Hu authored
Merge branch 'security-10-3-do-not-expose-passwords-or-tokens-in-service-integrations-api' into 'security-10-3' Filter out sensitive fields from the project services API See merge request gitlab/gitlabhq!2281 (cherry picked from commit 476f2576444632f2a9a61b4cead9c1077f2c81d7) 2bcbbda0 Filter out sensitive fields from the project services API
-
- 15 Jan, 2018 1 commit
-
-
Matija Čupić authored
-
- 14 Jan, 2018 1 commit
-
-
Matija Čupić authored
-
- 13 Jan, 2018 1 commit
-
-
Matija Čupić authored
The N+1 issue was caused by loading the job_artifacts_archive for each job (build) individually. Including that in the builds AssociationRelation fixed the issue.
-
- 11 Jan, 2018 1 commit
-
-
🙈 jacopo beschi 🙉 authored
-
- 09 Jan, 2018 1 commit
-
-
Francisco Javier López authored
-
- 08 Jan, 2018 1 commit
-
-
Yorick Peterse authored
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
-
- 04 Jan, 2018 1 commit
-
-
Felipe Artur authored
-
- 19 Dec, 2017 1 commit
-
-
Robert Speicher authored
Previously, this would include the entire User record in the update hash, which was rendered in the response using `to_json`, erroneously exposing every attribute of that record, including their (now removed) private token. Now we only include the user ID, and perform the lookup on-demand.
-
- 23 Nov, 2017 1 commit
-
-
Markus Koller authored
-
- 16 Nov, 2017 1 commit
-
-
Jacopo authored
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
-
- 08 Nov, 2017 1 commit
-
-
Douwe Maan authored
Use Commit#notes and Note.for_commit_id when possible to make sure we use all the indexes available to us
-
- 06 Nov, 2017 4 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Rémy Coutable authored
Mitigate a N+1 requests to Gitaly problem. Still one left. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 13 Oct, 2017 4 commits
-
-
Matt Coleman authored
-
Alejandro Rodríguez authored
Having a distinct class just for that was a bit overkill
-
Alejandro Rodríguez authored
Rename classes to (hopefully) clearer names while we're doing that.
-
Alejandro Rodríguez authored
-
- 12 Oct, 2017 1 commit
-
-
Guilherme Vieira authored
-
- 05 Oct, 2017 1 commit
-
-
Vitaliy @blackst0ne Klachkov authored
-
- 07 Sep, 2017 1 commit
-
-
Tiago Botelho authored
-
- 06 Sep, 2017 3 commits
-
-
Yorick Peterse authored
This finishes the procedure for migrating events from the old format into the new format. Code no longer uses the old setup and the database tables used during the migration process are swapped, with the old table being dropped. While the database migration can be reversed this will 1) take a lot of time as data has to be coped around 2) won't restore data in the "events.data" column as we have no way of restoring this. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37241
-
Ashley Dumaine authored
-
Ashley Dumaine authored
-
- 04 Sep, 2017 5 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- 16 Aug, 2017 1 commit
-
-
Zeger-Jan van de Weg authored
Main feature was the deprication of the Hashie stuff, so the access by calling keys as method is gone now.
-
- 14 Aug, 2017 2 commits
-
-
Robert Speicher authored
An upcoming update to rubocop-gitlab-security added additional violations.
-
Yorick Peterse authored
The number of forks of a project doesn't change very frequently and running a COUNT(*) every time this information is requested can be quite expensive. We also end up running such a COUNT(*) query at least twice on the homepage of a project. By caching this data and refreshing it when necessary we can reduce project homepage loading times by around 60 milliseconds (based on the timings of https://gitlab.com/gitlab-org/gitlab-ce).
-