- Aug 01, 2018
-
-
Zeger-Jan van de Weg authored
Our friends at GitHub show the programming languages for a long time, and inspired by that this commit means to create about the same functionality. Language detection is done through Linguist, as before, where the difference is that we cache the result in the database. Also, Gitaly can incrementaly scan a repository. This is done through a shell out, which creates overhead of about 3s each run. For now this won't be improved. Scans are triggered by pushed to the default branch, usually `master`. However, one exception to this rule the charts page. If we're requesting this expensive data anyway, we just cache it in the database. Edge cases where there is no repository, or its empty are caught in the Repository model. This makes use of Redis caching, which is probably already loaded. The added model is called RepositoryLanguage, which will make it harder if/when GitLab supports multiple repositories per project. However, for now I think this shouldn't be a concern. Also, Language could be confused with the i18n languages and felt like the current name was suiteable too. Design of the Project#Show page is done with help from @dimitrieh. This change is not visible to the end user unless detections are done.
-
- Jul 31, 2018
-
-
Jarka Kadlecova authored
-
- Jul 30, 2018
-
-
-
Jarka Kadlecova authored
-
- Jul 23, 2018
-
-
Francisco Javier López authored
-
- Jul 22, 2018
-
-
gfyoung authored
Enables frozen string for new files in directories that had been previously covered in previous MR's. Partially addresses #47424.
-
- Jul 20, 2018
-
-
Francisco Javier López authored
-
- Jul 19, 2018
-
-
George Thomas authored
If you enter the following RFC 2822 compliant address: `John Doe <john@doe.com>` Gitlab will attempt to send three emails: 1) John 2) Doe 3) john@doe.com With this change given the following: `John Doe <johndoe@example.com>` `Jane Doe <janedoe@example.com>` Gitlab will send emails to `johndoe@example.com` and `janedoe@example.com`
-
- Jul 18, 2018
-
-
Imre (Admin) authored
-
- Jul 10, 2018
-
-
Stan Hu authored
When the Gitaly call failed, the exception handling failed because `method` is expected to have a parameter. Closes #49096
-
Sean McGivern authored
-
- Jul 09, 2018
-
-
Lin Jen-Shin authored
-
Lin Jen-Shin authored
-
- Jul 06, 2018
-
-
Stan Hu authored
We saw in production that DispatchWorker was running about twice an hour, which would schedule twice as many jobs as it should. For some reason, BatchWorker was running 1000 times per hour, possibly due to Sidekiq RSS kills that caused these jobs to restart. Adding an ExclusiveLease prevents these jobs from running more than they should. Relates to https://gitlab.com/gitlab-com/infrastructure/issues/4526
-
Jan Provaznik authored
-
Shinya Maeda authored
-
- Jul 05, 2018
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-
- Jul 04, 2018
-
-
Sean McGivern authored
This reverts merge request !20103
-
- Jul 02, 2018
-
-
Yorick Peterse authored
This adds a recurring Sidekiq job that removes up to 50 000 old web hook logs per hour, if they are older than 90 days. This will prevent the web_hook_logs table from growing indefinitely. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/46120
-
- Jun 30, 2018
-
-
Imre (Admin) authored
-
- Jun 27, 2018
-
-
Toon Claes authored
There is only 1 `HEALTHY_SHARD_CHECKS` used: Gitlab::HealthChecks::GitalyCheck So we can simplify code to get the list of healthy shard names.
-
Toon Claes authored
-
Toon Claes authored
The RepositoryCheck::DispatchWorker will start a RepositoryCheck::BatchWorker for each healthy shard. Closes gitlab-org/gitlab-ce#48042
-
Toon Claes authored
It already existed in EE in the Geo namespace. This change brings it to CE.
-
Toon Claes authored
-
gfyoung authored
Partially addresses #47424.
-
gfyoung authored
-
- Jun 24, 2018
-
-
Oswaldo Ferreir authored
-
- Jun 21, 2018
-
-
Yorick Peterse authored
Various counters would expose either project names, or full project paths (e.g. "gitlab-org/gitlab-ce"). This commit changes various places where we use "add_event" so we no longer expose (potentially) private information.
-
- Jun 19, 2018
-
- Jun 18, 2018
-
-
Shinya Maeda authored
-
- Jun 13, 2018
-
- Jun 12, 2018
-
-
Jacob Vosmaer (GitLab) authored
-
- Jun 07, 2018
-
-
-
Kamil Trzcińśki authored
-
- Jun 06, 2018
-
-