Add latest changes from gitlab-org/gitlab@master

.eslintrc.yml

@@ -46,7 +46,6 @@ rules:
   promise/always-return: off
   promise/no-callback-in-promise: off
   promise/no-nesting: off
-  promise/param-names: off
   promise/valid-params: off
 overrides:
   files:

app/models/concerns/routable.rb

@@ -51,14 +51,21 @@ module Routable
     #     Klass.where_full_path_in(%w{gitlab-org/gitlab-foss gitlab-org/gitlab})
     #
     # Returns an ActiveRecord::Relation.
-    def where_full_path_in(paths)
+    def where_full_path_in(paths, use_includes: true)
       return none if paths.empty?
       wheres = paths.map do |path|
         "(LOWER(routes.path) = LOWER(#{connection.quote(path)}))"
       end
-      includes(:route).where(wheres.join(' OR ')).references(:routes)
+      route =
+        if use_includes
+          includes(:route).references(:routes)
+        else
+          joins(:route)
+        end
+
+      route.where(wheres.join(' OR '))
     end
   end

changelogs/unreleased/10904-insights-include-projects.yml

+---
+title: Add projects.only option to Insights
+merge_request: 15930
+author:
+type: added

changelogs/unreleased/sec-rep-mr-fixes.yml

+---
+title: Fixes issues with the security reports migration
+merge_request: 17519
+author:
+type: fixed

doc/administration/gitaly/index.md

@@ -3,7 +3,7 @@
 [Gitaly](https://gitlab.com/gitlab-org/gitaly) is the service that
 provides high-level RPC access to Git repositories. Without it, no other
 components can read or write Git data. GitLab components that access Git
-repositories (gitlab-rails, gitlab-shell, gitlab-workhorse, etc.) act as clients
+repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients
 to Gitaly. End users do not have direct access to Gitaly.
 In the rest of this page, Gitaly server is referred to the standalone node that
@@ -47,8 +47,8 @@ But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
 be leveraged for redudancy on block level of the Git data. But only has to
 be mounted on the Gitaly server.
-Starting with GitLab 11.8, it is possible to use ElasticSearch in conjunction with
-a Gitaly setup that isn't utilising NFS. In order to use ElasticSearch in this
+Starting with GitLab 11.8, it is possible to use Elasticsearch in conjunction with
+a Gitaly setup that isn't utilising NFS. In order to use Elasticsearch in this
 scenario, the [new repository indexer](../../integration/elasticsearch.md#elasticsearch-repository-indexer-beta)
 needs to be enabled in your GitLab configuration.
@@ -71,8 +71,8 @@ The following list depicts what the network architecture of Gitaly is:
 - A GitLab server can use one or more Gitaly servers.
 - Gitaly addresses must be specified in such a way that they resolve
   correctly for ALL Gitaly clients.
-- Gitaly clients are: Unicorn, Sidekiq, gitlab-workhorse,
-  gitlab-shell, Elasticsearch Indexer, and Gitaly itself.
+- Gitaly clients are: Unicorn, Sidekiq, GitLab Workhorse,
+  GitLab Shell, Elasticsearch Indexer, and Gitaly itself.
 - A Gitaly server must be able to make RPC calls **to itself** via its own
   `(Gitaly address, Gitaly token)` pair as specified in `/config/gitlab.yml`.
 - Gitaly servers must not be exposed to the public internet as Gitaly's network
@@ -576,7 +576,7 @@ machine.
 ### 1. Monitor current authentication behavior
-Use prometheus to see what the current authentication behavior of your
+Use Prometheus to see what the current authentication behavior of your
 GitLab installation is.
 ```
@@ -612,7 +612,7 @@ The second step is to temporarily disable authentication on the Gitaly servers.
 gitaly['auth_transitioning'] = true
 ```
-After you have applied this, your prometheus query should return
+After you have applied this, your Prometheus query should return
 something like this:
 ```
@@ -631,10 +631,10 @@ gitaly['auth_token'] = 'my new secret token'
 ```
 Remember to apply this on both your Gitaly clients *and* servers. If you
-check your prometheus query while this change is being rolled out, you
+check your Prometheus query while this change is being rolled out, you
 will see non-zero values for the `enforced="false",status="denied"` counter.
-### 4. Use prometheus to ensure there are no authentication failures
+### 4. Use Prometheus to ensure there are no authentication failures
 After you applied the Gitaly token change everywhere, and all services
 involved have been restarted, you should will temporarily see a mix of
@@ -658,7 +658,7 @@ gitaly['auth_transitioning'] = false
 ### 6. Verify that authentication is enforced again
-Refresh your prometheus query. You should now see the same kind of
+Refresh your Prometheus query. You should now see the same kind of
 result as you did in the beginning:
 ```

doc/administration/integration/plantuml.md

@@ -66,7 +66,13 @@ to the local PlantUML server `http://localhost:8080/plantuml`.
 To enable the redirection, add the following line in `/etc/gitlab/gitlab.rb`:
 ```ruby
-nginx['custom_gitlab_server_config'] = "location /-/plantuml { \n    proxy_cache off; \n    proxy_pass  http://127.0.0.1:8080; \n}\n"
+nginx['custom_gitlab_server_config'] = "location /-/plantuml/ { \n    proxy_cache off; \n    proxy_pass  http://127.0.0.1:8080/plantuml/; \n}\n"
+```
+
+To activate the changes, run the following command:
+
+```sh
+sudo gitlab-ctl reconfigure
 ```
 ## GitLab

doc/administration/logs.md

@@ -233,7 +233,7 @@ This file lives in `/var/log/gitlab/gitlab-shell/gitlab-shell.log` for
 Omnibus GitLab packages or in `/home/git/gitlab-shell/gitlab-shell.log` for
 installations from source.
-GitLab shell is used by GitLab for executing Git commands and provide
+GitLab Shell is used by GitLab for executing Git commands and provide
 SSH access to Git repositories. For example:
 ```
@@ -241,7 +241,7 @@ I, [2015-02-13T06:17:00.671315 #9291]  INFO -- : Adding project root/example.git
 I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git.
 ```
-User clone/fetch activity using ssh transport appears in this log as `executing git command <gitaly-upload-pack...`.
+User clone/fetch activity using SSH transport appears in this log as `executing git command <gitaly-upload-pack...`.
 ## `unicorn_stderr.log`
@@ -252,7 +252,7 @@ installations from source.
 Unicorn is a high-performance forking Web server which is used for
 serving the GitLab application. You can look at this log if, for
 example, your application does not respond. This log contains all
-information about the state of unicorn processes at any given time.
+information about the state of Unicorn processes at any given time.
 ```
 I, [2015-02-13T06:14:46.680381 #9047]  INFO -- : Refreshing Gem list

doc/administration/monitoring/index.md

@@ -10,4 +10,4 @@ Explore our features to monitor your GitLab instance:
 - [GitHub imports](github_imports.md): Monitor the health and progress of GitLab's GitHub importer with various Prometheus metrics.
 - [Monitoring uptime](../../user/admin_area/monitoring/health_check.md): Check the server status using the health check endpoint.
   - [IP whitelists](ip_whitelist.md): Configure GitLab for monitoring endpoints that provide health check information when probed.
-- [nginx_status](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your Nginx server status
+- [`nginx_status`](https://docs.gitlab.com/omnibus/settings/nginx.html#enablingdisabling-nginx_status): Monitor your NGINX server status

doc/administration/monitoring/performance/grafana_configuration.md

@@ -32,14 +32,14 @@ in the top bar.
 Fill in the configuration details for the InfluxDB data source. Save and
 Test Connection to ensure the configuration is correct.
-- **Name**: InfluxDB
+- **Name**: `InfluxDB`
 - **Default**: Checked
-- **Type**: InfluxDB 0.9.x (Even if you're using InfluxDB 0.10.x)
+- **Type**: `InfluxDB 0.9.x` (Even if you're using InfluxDB 0.10.x)
 - **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB
   on a separate server)
-- **Access**: proxy
-- **Database**: gitlab
-- **User**: admin (Or the username configured when setting up InfluxDB)
+- **Access**: `proxy`
+- **Database**: `gitlab`
+- **User**: `admin` (Or the username configured when setting up InfluxDB)
 - **Password**: The password configured when you set up InfluxDB
 ![Grafana data source configurations](img/grafana_data_source_configuration.png)

doc/administration/monitoring/performance/influxdb_configuration.md

@@ -95,7 +95,7 @@ UDP can be done using the following settings:
 This does the following:
 1. Enable UDP and bind it to port 8089 for all addresses.
-1. Store any data received in the "gitlab" database.
+1. Store any data received in the `gitlab` database.
 1. Define a batch of points to be 1000 points in size and allow a maximum of
    5 batches _or_ flush them automatically after 1 second.
 1. Define a UDP read buffer size of 200 MB.

doc/administration/monitoring/performance/prometheus.md

@@ -2,4 +2,4 @@
 redirect_to: '../prometheus/index.md'
 ---
-This document was moved to [monitoring/prometheus](../prometheus/index.md).
+This document was moved to [another location](../prometheus/index.md).

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -42,10 +42,10 @@ The following metrics are available:
 | `gitlab_transaction_cache_read_hit_count_total`                | Counter   |                   10.2 | Counter for cache hits for Rails cache calls                                                        | controller, action                                  |
 | `gitlab_transaction_cache_read_miss_count_total`               | Counter   |                   10.2 | Counter for cache misses for Rails cache calls                                                      | controller, action                                  |
 | `gitlab_transaction_duration_seconds`                          | Histogram |                   10.2 | Duration for all transactions (gitlab_transaction_* metrics)                                        | controller, action                                  |
-| `gitlab_transaction_event_build_found_total`                   | Counter   |                    9.4 | Counter for build found for api /jobs/request                                                       |                                                     |
-| `gitlab_transaction_event_build_invalid_total`                 | Counter   |                    9.4 | Counter for build invalid due to concurrency conflict for api /jobs/request                         |                                                     |
-| `gitlab_transaction_event_build_not_found_cached_total`        | Counter   |                    9.4 | Counter for cached response of build not found for api /jobs/request                                |                                                     |
-| `gitlab_transaction_event_build_not_found_total`               | Counter   |                    9.4 | Counter for build not found for api /jobs/request                                                   |                                                     |
+| `gitlab_transaction_event_build_found_total`                   | Counter   |                    9.4 | Counter for build found for API /jobs/request                                                       |                                                     |
+| `gitlab_transaction_event_build_invalid_total`                 | Counter   |                    9.4 | Counter for build invalid due to concurrency conflict for API /jobs/request                         |                                                     |
+| `gitlab_transaction_event_build_not_found_cached_total`        | Counter   |                    9.4 | Counter for cached response of build not found for API /jobs/request                                |                                                     |
+| `gitlab_transaction_event_build_not_found_total`               | Counter   |                    9.4 | Counter for build not found for API /jobs/request                                                   |                                                     |
 | `gitlab_transaction_event_change_default_branch_total`         | Counter   |                    9.4 | Counter when default branch is changed for any repository                                           |                                                     |
 | `gitlab_transaction_event_create_repository_total`             | Counter   |                    9.4 | Counter when any repository is created                                                              |                                                     |
 | `gitlab_transaction_event_etag_caching_cache_hit_total`        | Counter   |                    9.4 | Counter for etag cache hit.                                                                         | endpoint                                            |
@@ -66,10 +66,10 @@ The following metrics are available:
 | `gitlab_transaction_event_remove_branch_total`                 | Counter   |                    9.4 | Counter when a branch is removed for any repository                                                 |                                                     |
 | `gitlab_transaction_event_remove_repository_total`             | Counter   |                    9.4 | Counter when a repository is removed                                                                |                                                     |
 | `gitlab_transaction_event_remove_tag_total`                    | Counter   |                    9.4 | Counter when a tag is remove for any repository                                                     |                                                     |
-| `gitlab_transaction_event_sidekiq_exception_total`             | Counter   |                    9.4 | Counter of sidekiq exceptions                                                                       |                                                     |
+| `gitlab_transaction_event_sidekiq_exception_total`             | Counter   |                    9.4 | Counter of Sidekiq exceptions                                                                       |                                                     |
 | `gitlab_transaction_event_stuck_import_jobs_total`             | Counter   |                    9.4 | Count of stuck import jobs                                                                          | projects_without_jid_count, projects_with_jid_count |
-| `gitlab_transaction_event_update_build_total`                  | Counter   |                    9.4 | Counter for update build for api /jobs/request/:id                                                  |                                                     |
-| `gitlab_transaction_new_redis_connections_total`               | Counter   |                    9.4 | Counter for new redis connections                                                                   |                                                     |
+| `gitlab_transaction_event_update_build_total`                  | Counter   |                    9.4 | Counter for update build for API /jobs/request/:id                                                  |                                                     |
+| `gitlab_transaction_new_redis_connections_total`               | Counter   |                    9.4 | Counter for new Redis connections                                                                   |                                                     |
 | `gitlab_transaction_queue_duration_total`                      | Counter   |                    9.4 | Duration jobs were enqueued before processing                                                       |                                                     |
 | `gitlab_transaction_rails_queue_duration_total`                | Counter   |                    9.4 | Measures latency between GitLab Workhorse forwarding a request to Rails                             | controller, action                                  |
 | `gitlab_transaction_view_duration_total`                       | Counter   |                    9.4 | Duration for views                                                                                  | controller, action, view                            |

doc/administration/monitoring/prometheus/index.md

@@ -114,7 +114,7 @@ To use an external Prometheus server:
     gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
     ```
-1. To scrape nginx metrics, you'll also need to configure nginx to allow the Prometheus server
+1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
    IP. For example:
    ```ruby

doc/administration/operations/cleaning_up_redis_sessions.md

@@ -11,8 +11,8 @@ start building up again after you clean up.
 In GitLab versions prior to 7.3.0, the session keys in Redis are 16-byte
 hexadecimal values such as '976aa289e2189b17d7ef525a6702ace9'. Starting with
 GitLab 7.3.0, the keys are
-prefixed with 'session:gitlab:', so they would look like
-'session:gitlab:976aa289e2189b17d7ef525a6702ace9'. Below we describe how to
+prefixed with `session:gitlab:`, so they would look like
+`session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
 remove the keys in the old format.
 **Note:** the instructions below must be modified in accordance with your

doc/administration/operations/fast_ssh_key_lookup.md

@@ -2,7 +2,7 @@
 NOTE: **Note:** This document describes a drop-in replacement for the
 `authorized_keys` file for normal (non-deploy key) users. Consider
-using [ssh certificates](ssh_certificates.md), they are even faster,
+using [SSH certificates](ssh_certificates.md), they are even faster,
 but are not a drop-in replacement.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in
@@ -78,7 +78,7 @@ CAUTION: **Caution:** Do not disable writes until SSH is confirmed to be working
 perfectly, because the file will quickly become out-of-date.
 In the case of lookup failures (which are common), the `authorized_keys`
-file will still be scanned. So git SSH performance will still be slow for many
+file will still be scanned. So Git SSH performance will still be slow for many
 users as long as a large file exists.
 You can disable any more writes to the `authorized_keys` file by unchecking

doc/administration/operations/moving_repositories.md

@@ -31,7 +31,7 @@ If you want to see progress, replace `-xf` with `-xvf`.
 ### Tar pipe to another server
 You can also use a tar pipe to copy data to another server. If your
-'git' user has SSH access to the newserver as 'git@newserver', you
+`git` user has SSH access to the newserver as `git@newserver`, you
 can pipe the data through SSH.
 ```
@@ -61,7 +61,7 @@ If you want to see progress, replace `-a` with `-av`.
 ### Single rsync to another server
-If the 'git' user on your source system has SSH access to the target
+If the `git` user on your source system has SSH access to the target
 server you can send the repositories over the network with rsync.
 ```
@@ -95,7 +95,7 @@ after switching to the new repository storage directory.
 This will sync repositories with 10 rsync processes at a time. We keep
 track of progress so that the transfer can be restarted if necessary.
-First we create a new directory, owned by 'git', to hold transfer
+First we create a new directory, owned by `git`, to hold transfer
 logs. We assume the directory is empty before we start the transfer
 procedure, and that we are the only ones writing files in it.

doc/administration/operations/sidekiq_memory_killer.md

@@ -2,7 +2,7 @@
 The GitLab Rails application code suffers from memory leaks. For web requests
 this problem is made manageable using
-[unicorn-worker-killer](https://github.com/kzk/unicorn-worker-killer) which
+[`unicorn-worker-killer`](https://github.com/kzk/unicorn-worker-killer) which
 restarts Unicorn worker processes in between requests when needed. The Sidekiq
 MemoryKiller applies the same approach to the Sidekiq processes used by GitLab
 to process background jobs.
@@ -10,8 +10,8 @@ to process background jobs.
 Unlike unicorn-worker-killer, which is enabled by default for all GitLab
 installations since GitLab 6.4, the Sidekiq MemoryKiller is enabled by default
 _only_ for Omnibus packages. The reason for this is that the MemoryKiller
-relies on Runit to restart Sidekiq after a memory-induced shutdown and GitLab
-installations from source do not all use Runit or an equivalent.
+relies on runit to restart Sidekiq after a memory-induced shutdown and GitLab
+installations from source do not all use runit or an equivalent.
 With the default settings, the MemoryKiller will cause a Sidekiq restart no
 more often than once every 15 minutes, with the restart causing about one
@@ -49,7 +49,7 @@ The MemoryKiller is controlled using environment variables.
   the restart will be aborted.
   The default value for Omnibus packages is set
-  [in the omnibus-gitlab
+  [in the Omnibus GitLab
   repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb).
 - `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`: is used by _daemon_ mode. If the Sidekiq
@@ -72,4 +72,4 @@ The MemoryKiller is controlled using environment variables.
   If the process hard shutdown/restart is not performed by Sidekiq,
   the Sidekiq process will be forcefully terminated after
   `Sidekiq.options[:timeout] * 2` seconds. An external supervision mechanism
-  (e.g. Runit) must restart Sidekiq afterwards.
+  (e.g. runit) must restart Sidekiq afterwards.

doc/administration/operations/ssh_certificates.md

@@ -3,7 +3,7 @@
 > [Available in](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/19911) GitLab
 > Community Edition 11.2.
-GitLab's default SSH authentication requires users to upload their ssh
+GitLab's default SSH authentication requires users to upload their SSH
 public keys before they can use the SSH transport.
 In centralized (e.g. corporate) environments this can be a hassle

doc/administration/operations/unicorn.md

@@ -40,7 +40,7 @@ master process has PID 56227 below.
 The main tunables for Unicorn are the number of worker processes and the
 request timeout after which the Unicorn master terminates a worker process.
-See the [omnibus-gitlab Unicorn settings
+See the [Omnibus GitLab Unicorn settings
 documentation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md)
 if you want to adjust these settings.

doc/administration/packages/container_registry.md

@@ -360,9 +360,9 @@ The different supported drivers are:
 | Driver     | Description                         |
 |------------|-------------------------------------|
 | filesystem | Uses a path on the local filesystem |
-| azure      | Microsoft Azure Blob Storage        |
+| Azure      | Microsoft Azure Blob Storage        |
 | gcs        | Google Cloud Storage                |
-| s3         | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes).       |
+| s3         | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
 | swift      | OpenStack Swift Object Storage      |
 | oss        | Aliyun OSS                          |
@@ -374,7 +374,7 @@ filesystem. Remember to enable backups with your object storage provider if
 desired.
 NOTE: **Note:**
-`regionendpoint` is only required when configuring an S3 compatible service such as Minio. It takes a URL such as `http://127.0.0.1:9000`.
+`regionendpoint` is only required when configuring an S3 compatible service such as MinIO. It takes a URL such as `http://127.0.0.1:9000`.
 **Omnibus GitLab installations**