Add latest changes from gitlab-org/gitlab@13-0-stable-ee

7 files changed, 113 insertions, 69 deletions

diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index 77a63112ea3..a39fe4ba8c3 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -1,5 +1,8 @@
 # Troubleshooting Elasticsearch
 
+To install and configure Elasticsearch, and for common and known issues,
+visit the [administrator documentation](../../integration/elasticsearch.md).
+
 Troubleshooting Elasticsearch requires:
 
 - Knowledge of common terms.
@@ -203,7 +206,7 @@ The best place to start is to determine if the issue is with creating an empty i
 If it is, check on the Elasticsearch side to determine if the `gitlab-production` (the
 name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch
 side and attempt to recreate it from the
-[`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
+[`recreate_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
 Rake task.
 
 If you still encounter issues, try creating an index manually on the Elasticsearch
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index ba2224e3fc7..2cbc994fb4c 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -150,9 +150,9 @@ Project.update_all(visibility_level: 0)
 #
 projects = Project.where(pending_delete: true)
 projects.each do |p|
-  puts "Project name: #{p.id}"
+  puts "Project ID: #{p.id}"
   puts "Project name: #{p.name}"
-  puts "Repository path: #{p.repository.storage_path}"
+  puts "Repository path: #{p.repository.full_path}"
 end
 
 #
@@ -214,6 +214,20 @@ p.each do |project|
 end
 ```
 
+### Bulk update to disable the Slack Notification service
+
+To disable notifications for all projects that have Slack service enabled, do:
+
+```ruby
+# Grab all projects that have the Slack notifications enabled
+p = Project.find_by_sql("SELECT p.id FROM projects p LEFT JOIN services s ON p.id = s.project_id WHERE s.type = 'SlackService' AND s.active = true")
+
+# Disable the service on each of the projects that were found.
+p.each do |project|
+  project.slack_service.update_attribute(:active, false)
+end
+```
+
 ## Wikis
 
 ### Recreate
@@ -558,29 +572,7 @@ Ci::Pipeline.where(project_id: p.id).where(status: 'pending').count
 
 ### Remove artifacts more than a week old
 
-The Latest version of these steps can be found in the [job artifacts documentation](../job_artifacts.md)
-
-```ruby
-### SELECTING THE BUILDS TO CLEAR
-# For a single project:
-project = Project.find_by_full_path('')
-builds_with_artifacts =  project.builds.with_artifacts_archive
-
-# Instance-wide:
-builds_with_artifacts = Ci::Build.with_artifacts_archive
-
-# Prior to 10.6 the above lines would be:
-# builds_with_artifacts =  project.builds.with_artifacts
-# builds_with_artifacts = Ci::Build.with_artifacts
-
-### CLEAR THEM OUT
-# Note that this will also erase artifacts that developers marked to "Keep"
-builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
-builds_to_clear.each do |build|
-  build.artifacts_expire_at = Time.now
-  build.erase_erasable_artifacts!
-end
-```
+This section has been moved to the [job artifacts troubleshooting documentation](../job_artifacts.md#delete-job-artifacts-from-jobs-completed-before-a-specific-date).
 
 ### Find reason failure (for when build trace is empty) (Introduced in 10.3.0)
 
@@ -603,6 +595,14 @@ m = project.merge_requests.find_by(iid: )
 m.project.try(:ci_service)
 ```
 
+### Validate the `.gitlab-ci.yml`
+
+```ruby
+project = Project.find_by_full_path 'group/project'
+content = project.repository.gitlab_ci_yml_for(project.repository.root_ref_sha)
+Gitlab::Ci::YamlProcessor.validation_message(content,  user: User.first)
+```
+
 ### Disable AutoDevOps on Existing Projects
 
 ```ruby
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 30ef3da3a99..cab073b9924 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -52,7 +52,7 @@ and they will assist you with any issues you are having.
   - Check logs via Kubectl:
 
     ```shell
-    kubectl logs <unicorn pod> -c dependencies
+    kubectl logs <webservice pod> -c dependencies
     ```
 
 - How to tail all Kubernetes cluster events in real time:
@@ -72,7 +72,7 @@ and they will assist you with any issues you are having.
   This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
   for details.
 
-- How to get cronjobs configured on a cluster
+- How to get cron jobs configured on a cluster
 
   ```shell
   kubectl get cronjobs
@@ -87,20 +87,20 @@ and they will assist you with any issues you are having.
 - Minimal config that can be used to test a Kubernetes Helm chart can be found
   [here](https://gitlab.com/gitlab-org/charts/gitlab/issues/620).
 
-- Tailing logs of a separate pod. An example for a Unicorn pod:
+- Tailing logs of a separate pod. An example for a Webservice pod:
 
   ```shell
-  kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
+  kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice
   ```
 
-- Tail and follow all pods that share a label (in this case, `unicorn`):
+- Tail and follow all pods that share a label (in this case, `webservice`):
 
   ```shell
-  # all containers in the unicorn pods
-  kubectl logs -f -l app=unicorn --all-containers=true --max-log-requests=50
+  # all containers in the webservice pods
+  kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50
 
-  # only the unicorn containers in all unicorn pods
-  kubectl logs -f -l app=unicorn -c unicorn --max-log-requests=50
+  # only the webservice containers in all webservice pods
+  kubectl logs -f -l app=webservice -c webservice --max-log-requests=50
   ```
 
 - One can stream logs from all containers at once, similar to the Omnibus
@@ -132,7 +132,7 @@ and they will assist you with any issues you are having.
   /srv/gitlab/bin/rails console
 
   # source-style commands should also work
-  /srv/gitlab && bundle exec rake gitlab:check RAILS_ENV=production
+  cd /srv/gitlab && bundle exec rake gitlab:check RAILS_ENV=production
 
   # run GitLab check. Note that the output can be confusing and invalid because of the specific structure of GitLab installed via helm chart
   /usr/local/bin/gitlab-rake gitlab:check
@@ -206,7 +206,7 @@ all Kubernetes resources and dependent charts:
   helm get manifest <release name>
   ```
 
-## Installation of minimal GitLab config via Minukube on macOS
+## Installation of minimal GitLab config via Minikube on macOS
 
 This section is based on [Developing for Kubernetes with Minikube](https://docs.gitlab.com/charts/development/minikube/index.html)
 and [Helm](https://docs.gitlab.com/charts/installation/tools.html#helm). Refer
@@ -230,31 +230,33 @@ to those documents for details.
   ```shell
   minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
   minikube addons enable ingress
-  minikube addons enable kube-dns
   ```
 
 - Install Helm via Homebrew and initialize it:
 
   ```shell
-  brew install kubernetes-helm
-  helm init --service-account tiller
+  brew install helm
   ```
 
-- Copy the file <https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml>
-  to your workstation.
+- Copy the [Minikube minimum values YAML file](https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml)
+  to your workstation:
 
-- Find the IP address in the output of `minikube ip` and update the yaml file with
+  ```shell
+  curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"
+  ```
+
+- Find the IP address in the output of `minikube ip` and update the YAML file with
   this IP address.
 
 - Install the GitLab Helm Chart:
 
   ```shell
   helm repo add gitlab https://charts.gitlab.io
-  helm install --name gitlab -f <path-to-yaml-file> gitlab/gitlab
+  helm install gitlab -f <path-to-yaml-file> gitlab/gitlab
   ```
 
   If you want to modify some GitLab settings, you can use the above-mentioned config
-  as a base and create your own yaml file.
+  as a base and create your own YAML file.
 
 - Monitor the installation progress via `helm status gitlab` and `minikube dashboard`.
   The installation could take up to 20-30 minutes depending on the amount of resources
@@ -263,7 +265,7 @@ to those documents for details.
 - When all the pods show either a `Running` or `Completed` status, get the GitLab password as
   described in [Initial login](https://docs.gitlab.com/charts/installation/deployment.html#initial-login),
   and log in to GitLab via the UI. It will be accessible via `https://gitlab.domain`
-  where `domain` is the value provided in the yaml file.
+  where `domain` is the value provided in the YAML file.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/administration/troubleshooting/log_parsing.md b/doc/administration/troubleshooting/log_parsing.md
index 0413e5ce953..dcd1df2f423 100644
--- a/doc/administration/troubleshooting/log_parsing.md
+++ b/doc/administration/troubleshooting/log_parsing.md
@@ -16,19 +16,19 @@ include use cases targeted for parsing GitLab log files.
 
 #### Pipe colorized `jq` output into `less`
 
-```sh
+```shell
 jq . <FILE> -C | less -R
 ```
 
 #### Search for a term and pretty-print all matching lines
 
-```sh
+```shell
 grep <TERM> <FILE> | jq .
 ```
 
 #### Skip invalid lines of JSON
 
-```sh
+```shell
 jq -cR 'fromjson?' file.json | jq <COMMAND>
 ```
 
@@ -39,49 +39,49 @@ This skips over all invalid lines and parses the rest.
 
 #### Find all requests with a 5XX status code
 
-```sh
+```shell
 jq 'select(status >= 500)' <FILE>
 ```
 
 #### Top 10 slowest requests
 
-```sh
+```shell
 jq -s 'sort_by(-.duration) | limit(10; .[])' <FILE>
 ```
 
 #### Find and pretty print all requests related to a project
 
-```sh
+```shell
 grep <PROJECT_NAME> <FILE> | jq .
 ```
 
 #### Find all requests with a total duration > 5 seconds
 
-```sh
+```shell
 jq 'select(.duration > 5000)' <FILE>
 ```
 
 #### Find all project requests with more than 5 rugged calls
 
-```sh
+```shell
 grep <PROJECT_NAME> <FILE> | jq 'select(.rugged_calls > 5)'
 ```
 
 #### Find all requests with a Gitaly duration > 10 seconds
 
-```sh
+```shell
 jq 'select(.gitaly_duration > 10000)' <FILE>
 ```
 
 #### Find all requests with a queue duration > 10 seconds
 
-```sh
+```shell
 jq 'select(.queue_duration > 10000)' <FILE>
 ```
 
 #### Top 10 requests by # of Gitaly calls
 
-```sh
+```shell
 jq -s 'map(select(.gitaly_calls != null)) | sort_by(-.gitaly_calls) | limit(10; .[])' <FILE>
 ```
 
@@ -89,7 +89,7 @@ jq -s 'map(select(.gitaly_calls != null)) | sort_by(-.gitaly_calls) | limit(10;
 
 #### Print the top three controller methods by request volume and their three longest durations
 
-```sh
+```shell
 jq -s -r 'group_by(.controller+.action) | sort_by(-length) | limit(3; .[]) | sort_by(-.duration) | "CT: \(length)\tMETHOD: \(.[0].controller)#\(.[0].action)\tDURS: \(.[0].duration),  \(.[1].duration),  \(.[2].duration)"' production_json.log
 ```
 
@@ -105,7 +105,7 @@ CT: 1328   METHOD: Projects::NotesController#index DURS: 403.99,  386.29,  384.3
 
 #### Print top three routes with request count and their three longest durations
 
-```sh
+```shell
 jq -s -r 'group_by(.route) | sort_by(-length) | limit(3; .[]) | sort_by(-.duration) | "CT: \(length)\tROUTE: \(.[0].route)\tDURS: \(.[0].duration),  \(.[1].duration),  \(.[2].duration)"' api_json.log
 ```
 
@@ -121,25 +121,25 @@ CT: 190  ROUTE: /api/:version/projects/:id/repository/commits    DURS: 1079.02,
 
 #### Find all Gitaly requests sent from web UI
 
-```sh
+```shell
 jq 'select(."grpc.meta.client_name" == "gitlab-web")' current
 ```
 
 #### Find all failed Gitaly requests
 
-```sh
+```shell
 jq 'select(."grpc.code" != null and ."grpc.code" != "OK")' current
 ```
 
 #### Find all requests that took longer than 30 seconds
 
-```sh
+```shell
 jq 'select(."grpc.time_ms" > 30000)' current
 ```
 
 #### Print top three projects by request volume and their three longest durations
 
-```sh
+```shell
 jq -s -r 'map(select(."grpc.request.glProjectPath" != null and ."grpc.request.glProjectPath" != "" and ."grpc.time_ms" != null)) | group_by(."grpc.request.glProjectPath") | sort_by(-length) | limit(3; .[]) | sort_by(-."grpc.time_ms") | "CT: \(length)\tPROJECT: \(.[0]."grpc.request.glProjectPath")\tDURS: \(.[0]."grpc.time_ms"),  \(.[1]."grpc.time_ms"),  \(.[2]."grpc.time_ms")"' current
 ```
 
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index 8e7727ee214..65a6bffca44 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -33,7 +33,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - [More about external PostgreSQL](../external_database.md)
 
-- [Running GEO with external PostgreSQL](../geo/replication/external_database.md)
+- [Running Geo with external PostgreSQL](../geo/replication/external_database.md)
 
 - [Upgrades when running PostgreSQL configured for HA.](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-gitlab-ha-cluster)
 
@@ -45,7 +45,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
 
-- [PostgreSQL scaling and HA](../high_availability/database.md)
+- [PostgreSQL scaling](../high_availability/database.md)
   - including [troubleshooting](../high_availability/database.md#troubleshooting) `gitlab-ctl repmgr-check-master` and PgBouncer errors
 
 - [Developer database documentation](../../development/README.md#database-guides) - some of which is absolutely not for production use. Including:
@@ -71,7 +71,7 @@ This section is for links to information elsewhere in the GitLab documentation.
   HINT:  Free one or increase max_replication_slots.
   ```
 
-- GEO [replication errors](../geo/replication/troubleshooting.md#fixing-replication-errors) including:
+- Geo [replication errors](../geo/replication/troubleshooting.md#fixing-replication-errors) including:
 
   ```plaintext
   ERROR: replication slots can only be used if max_replication_slots > 0
@@ -83,11 +83,11 @@ This section is for links to information elsewhere in the GitLab documentation.
   PANIC: could not write to file ‘pg_xlog/xlogtemp.123’: No space left on device
   ```
 
-- [Checking GEO configuration](../geo/replication/troubleshooting.md#checking-configuration) including
+- [Checking Geo configuration](../geo/replication/troubleshooting.md#checking-configuration) including
   - reconfiguring hosts/ports
   - checking and fixing user/password mappings
 
-- [Common GEO errors](../geo/replication/troubleshooting.md#fixing-common-errors)
+- [Common Geo errors](../geo/replication/troubleshooting.md#fixing-common-errors)
 
 ## Support topics
 
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index 31e41725834..ca21c038267 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -282,7 +282,8 @@ Commonly, `<condition>` references the job arguments, which depend on the type o
 
 For example, `repository_import` has `project_id` as the job argument, while `update_merge_requests` has `project_id, user_id, oldrev, newrev, ref`.
 
-NOTE: **Note:** Arguments need to be referenced by their sequence id using `job.args[<id>]` because `job.args` is a list of all arguments provided to the Sidekiq job.
+NOTE: **Note:**
+Arguments need to be referenced by their sequence ID using `job.args[<id>]` because `job.args` is a list of all arguments provided to the Sidekiq job.
 
 Here are some examples:
 
diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md
index f230f047ded..e6c081e1eea 100644
--- a/doc/administration/troubleshooting/ssl.md
+++ b/doc/administration/troubleshooting/ssl.md
@@ -46,6 +46,44 @@ After configuring a GitLab instance with an internal CA certificate, you might n
 
 If you have the problems listed above, add your certificate to `/etc/gitlab/trusted-certs` and run `sudo gitlab-ctl reconfigure`.
 
+## X.509 key values mismatch error
+
+After configuring your instance with a certificate bundle, NGINX may throw the
+following error:
+
+`SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch`
+
+This error means that the server certificate and key you have provided do not
+match. You can confirm this by running the following command and comparing the
+output:
+
+```shell
+openssl rsa -noout -modulus -in path/to/your/.key | openssl md5
+openssl x509 -noout -modulus -in path/to/your/.crt | openssl md5
+```
+
+The following is an example of an md5 output between a matching key and certificate. Note the
+matching md5 hashes:
+
+```shell
+$ openssl rsa -noout -modulus -in private.key | openssl md5
+4f49b61b25225abeb7542b29ae20e98c
+$ openssl x509 -noout -modulus -in public.crt | openssl md5
+4f49b61b25225abeb7542b29ae20e98c
+```
+
+This is an opposing output with a non-matching key and certificate which shows different md5 hashes:
+
+```shell
+$ openssl rsa -noout -modulus -in private.key | openssl md5
+d418865077299af27707b1d1fa83cd99
+$ openssl x509 -noout -modulus -in public.crt | openssl md5
+4f49b61b25225abeb7542b29ae20e98c
+```
+
+If the two outputs differ like the above example, there is a mismatch between the certificate
+and key. You should contact the provider of the SSL certificate for further support.
+
 ## Using GitLab Runner with a GitLab instance configured with internal CA certificate or self-signed certificate
 
 Besides getting the errors mentioned in