Add latest changes from gitlab-org/gitlab@master

18 files changed, 72 insertions, 70 deletions

diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index 5ef739a4289..89b454a73a0 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -105,7 +105,7 @@ bundle exec rake file_hooks:validate RAILS_ENV=production
 
 Example of output:
 
-```
+```plaintext
 Validating file hooks from /plugins directory
 * /home/git/gitlab/plugins/save_to_file.clj succeed (zero exit code)
 * /home/git/gitlab/plugins/save_to_file.rb failure (non-zero exit code)
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index b07b518d3b1..8a3439d2aaa 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -45,7 +45,7 @@ query.
 
 ## Can I `git push` to a **secondary** node?
 
-Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 ## How long does it take to have a commit replicated to a **secondary** node?
 
diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md
index 04f61775b29..e3699f1544b 100644
--- a/doc/administration/geo/replication/index.md
+++ b/doc/administration/geo/replication/index.md
@@ -63,7 +63,7 @@ Keep in mind that:
   - Get user data for logins (API).
   - Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
 - Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
-- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 - There are [limitations](#current-limitations) in the current implementation.
 
 ### Architecture
diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md
index 68bf5b5d23a..3da71cab48d 100644
--- a/doc/administration/geo/replication/security_review.md
+++ b/doc/administration/geo/replication/security_review.md
@@ -2,8 +2,8 @@
 
 The following security review of the Geo feature set focuses on security aspects of
 the feature as they apply to customers running their own GitLab instances. The review
-questions are based in part on the [OWASP Application Security Verification Standard Project](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project)
-from [owasp.org](https://www.owasp.org/index.php/Main_Page).
+questions are based in part on the [OWASP Application Security Verification Standard Project](https://owasp.org/www-project-application-security-verification-standard/)
+from [owasp.org](https://www.owasp.org/).
 
 ## Business Model
 
diff --git a/doc/administration/geo/replication/using_a_geo_server.md b/doc/administration/geo/replication/using_a_geo_server.md
index 37982f2756c..b814bcf8459 100644
--- a/doc/administration/geo/replication/using_a_geo_server.md
+++ b/doc/administration/geo/replication/using_a_geo_server.md
@@ -4,7 +4,7 @@
 
 After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.
 
-Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 Example of the output you will see when pushing to a **secondary** node:
 
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index 738eb87d53d..3689a604840 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world.
 
 1. Install the Pages daemon:
 
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -160,7 +160,7 @@ outside world.
 
 1. Install the Pages daemon:
 
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS.
 
 1. Install the Pages daemon:
 
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -290,7 +290,7 @@ world. Custom domains and TLS are supported.
 
 1. Install the Pages daemon:
 
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -353,20 +353,20 @@ not remove the backslashes.
 
 If your GitLab Pages domain is `example.io`, replace:
 
-```bash
+```nginx
 server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
 ```
 
 with:
 
-```
+```nginx
 server_name ~^.*\.example\.io$;
 ```
 
 If you are using a subdomain, make sure to escape all dots (`.`) except from
 the first one with a backslash (\). For example `pages.example.io` would be:
 
-```
+```nginx
 server_name ~^.*\.pages\.example\.io$;
 ```
 
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index eb230f02c0d..7f3405df060 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -33,7 +33,7 @@ integrity check described previously.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:git:fsck
 ```
 
@@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file:
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:artifacts:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check
@@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
 
 Example output:
 
-```
+```bash
 $ sudo gitlab-rake gitlab:uploads:check
 Checking integrity of Uploads
 - 1..1350: Failures: 0
@@ -107,7 +107,7 @@ Done!
 
 Example verbose output:
 
-```
+```bash
 $ sudo gitlab-rake gitlab:uploads:check VERBOSE=1
 Checking integrity of Uploads
 - 1..1350: Failures: 0
diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md
index 09f72c3411d..8bf720d2872 100644
--- a/doc/administration/raketasks/geo.md
+++ b/doc/administration/raketasks/geo.md
@@ -11,7 +11,7 @@ This is equivalent of running `git repack -d` on a _bare_ repository.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:incremental_repack
 ```
 
@@ -29,7 +29,7 @@ when this is enabled in GitLab.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:full_repack
 ```
 
@@ -46,7 +46,7 @@ a reachability bitmap index when this is enabled in GitLab.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:gc
 ```
 
@@ -63,7 +63,7 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake geo:run_orphaned_project_registry_cleaner
 ```
 
diff --git a/doc/administration/raketasks/ldap.md b/doc/administration/raketasks/ldap.md
index 36db98a2102..41a9a4192cf 100644
--- a/doc/administration/raketasks/ldap.md
+++ b/doc/administration/raketasks/ldap.md
@@ -9,7 +9,7 @@ using the command below.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:ldap:check
 ```
 
@@ -41,7 +41,7 @@ instead.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:ldap:group_sync
 ```
 
@@ -101,7 +101,7 @@ sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
 
 Example output:
 
-```
+```plaintext
 100 users with provider 'ldapmain' will be updated to 'ldapmycompany'.
 If the new provider is incorrect, users will be unable to sign in.
 Do you want to continue (yes/no)? yes
@@ -128,7 +128,7 @@ bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
 
 **Example output:**
 
-```
+```plaintext
 What is the old provider? Ex. 'ldapmain': ldapmain
 What is the new provider? Ex. 'ldapcustom': ldapmycompany
 ```
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 149b8d62309..efc7a84a80e 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -6,19 +6,19 @@ This command gathers information about your GitLab installation and the System i
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:env:info
 ```
 
 **Source Installation**
 
-```
+```bash
 bundle exec rake gitlab:env:info RAILS_ENV=production
 ```
 
 Example output:
 
-```
+```plaintext
 System information
 System:           Debian 7.8
 Current User:     git
@@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides:
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:check
 ```
 
 **Source Installation**
 
-```
+```bash
 bundle exec rake gitlab:check RAILS_ENV=production
 ```
 
@@ -80,7 +80,7 @@ NOTE: Use `SANITIZE=true` for `gitlab:check` if you want to omit project names f
 
 Example output:
 
-```
+```plaintext
 Checking Environment ...
 
 Git configured for git user? ... yes
@@ -129,18 +129,18 @@ In some case it is necessary to rebuild the `authorized_keys` file.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:shell:setup
 ```
 
 **Source Installation**
 
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
 ```
 
-```
+```plaintext
 This will rebuild an authorized_keys file.
 You will lose any data stored in authorized_keys file.
 Do you want to continue (yes/no)? yes
@@ -153,13 +153,13 @@ clear Redis' cache.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake cache:clear
 ```
 
 **Source Installation**
 
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
 ```
@@ -174,7 +174,7 @@ Omnibus packages.
 
 **Source Installation**
 
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
 ```
@@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database.
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:track_deployment
 ```
 
 **Source Installation**
 
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
 ```
@@ -213,13 +213,13 @@ is included to help you with this:
 
 **Omnibus Installation**
 
-```
+```bash
 sudo gitlab-rake gitlab:tcp_check[example.com,80]
 ```
 
 **Source Installation**
 
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
 ```
@@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome
 
 To re-import the metrics you can run:
 
-```sh
+```bash
 sudo gitlab-rake metrics:setup_common_metrics
 ```
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index e95fbff74b3..dee460348f3 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -659,8 +659,6 @@ procfile exec` to replicate the environment where your application will run.
 
 #### Workers
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
-
 Some web applications need to run extra deployments for "worker processes". For
 example, it is common in a Rails application to have a separate worker process
 to run background tasks like sending emails.
@@ -683,17 +681,8 @@ need to:
   ensure it's passed into your deployments.
 
 Once you have configured your worker to respond to health checks, run a Sidekiq
-worker for your Rails application. For:
-
-- GitLab 12.6 and later, either:
-  - Add a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
-    be automatically used if found.
-  - Add a file with a different name or path to the repository, and override the value of the
-    `HELM_UPGRADE_VALUES_FILE` variable with the path and name.
-- GitLab 12.5 and earlier, run the worker with the `--values` parameter that specifies
-  a file in the repository.
-
-In any case, the file must contain the following:
+worker for your Rails application. You can enable workers by setting the
+following in the [`.gitlab/auto-deploy-values.yaml` file](#customize-values-for-helm-chart):
 
 ```yml
 workers:
@@ -927,8 +916,21 @@ repo or by specifying a project variable:
 - **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
   `AUTO_DEVOPS_CHART` with the URL of a custom chart to use or create two project variables `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository and `AUTO_DEVOPS_CHART` with the path to the chart.
 
-You can also make use of the `HELM_UPGRADE_EXTRA_ARGS` environment variable to override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
-To apply your own `values.yaml` file to all Helm upgrade commands in Auto Deploy set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
+### Customize values for Helm Chart
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
+
+You can override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
+This can be achieved by either:
+
+- Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
+  be automatically used if found.
+- Adding a file with a different name or path to the repository, and set the
+  `HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with the path and name.
+
+NOTE: **Note:**
+For GitLab 12.5 and earlier, the `HELM_UPGRADE_EXTRA_ARGS` environment variable can be used to override the default chart values.
+To do so, set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
 
 ### Custom Helm chart per environment
 
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index 220ce2593bb..94b07af0985 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -78,7 +78,7 @@ service: gitlab-example
 provider:
   name: aws
   runtime: nodejs10.x
-  
+
 functions:
   hello:
     handler: src/handler.hello
@@ -222,7 +222,7 @@ From there, you can reference them in your functions as well.
 Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
 
 NOTE: **Note:**
-Anyone with access to the AWS environemnt may be able to see the values of those
+Anyone with access to the AWS environment may be able to see the values of those
 variables persisted in the lambda definition.
 
 ### Setting up CORS
diff --git a/doc/user/project/integrations/prometheus_library/cloudwatch.md b/doc/user/project/integrations/prometheus_library/cloudwatch.md
index d0148828a21..b81b58fa619 100644
--- a/doc/user/project/integrations/prometheus_library/cloudwatch.md
+++ b/doc/user/project/integrations/prometheus_library/cloudwatch.md
@@ -12,9 +12,9 @@ The [Prometheus service](../prometheus.md) must be enabled.
 
 | Name | Query |
 | ---- | ----- |
-| Throughput (req/sec) | sum(aws_elb_request_count_sum{%{environment_filter}}) / 60 |
-| Latency (ms) | avg(aws_elb_latency_average{%{environment_filter}}) * 1000 |
-| HTTP Error Rate (%) | sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}}) |
+| Throughput (req/sec) | `sum(aws_elb_request_count_sum{%{environment_filter}}) / 60` |
+| Latency (ms) | `avg(aws_elb_latency_average{%{environment_filter}}) * 1000` |
+| HTTP Error Rate (%) | `sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}})` |
 
 ## Configuring Prometheus to monitor for Cloudwatch metrics
 
diff --git a/doc/user/project/issues/csv_export.md b/doc/user/project/issues/csv_export.md
index 13f0c11399f..844b27ae297 100644
--- a/doc/user/project/issues/csv_export.md
+++ b/doc/user/project/issues/csv_export.md
@@ -62,8 +62,8 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 | Confidential | `Yes` or `No` |
 | Locked | `Yes` or `No` |
 | Due Date | Formated as `YYYY-MM-DD` |
-| Created At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
-| Updated At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
+| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
+| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
 | Milestone | Title of the issue milestone |
 | Weight | Issue weight |
 | Labels | Title of any labels joined with a `,` |
diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index 5b4c6d22c80..470cf2a8656 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -17,7 +17,7 @@ or through the GitLab UI.
 
 This document describes the several ways to create a merge request.
 
-When you start a new merge request, regarless of the method,
+When you start a new merge request, regardless of the method,
 you'll be taken to the [**New Merge Request** page](#new-merge-request-page)
 to fill it with information about the merge request.
 
@@ -29,9 +29,9 @@ button and start a merge request from there.
 
 On the **New Merge Request** page, start by filling in the title
 and description for the merge request. If there are are already
-commits on the branch, the title will be pre-filled with the first
+commits on the branch, the title will be prefilled with the first
 line of the first commit message, and the description will be
-pre-filled with any additional lines in the commit message.
+prefilled with any additional lines in the commit message.
 The title is the only field that is mandatory in all cases.
 
 From there, you can fill it with information (title, description,
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index e1ac8b2183c..cc3e00bc098 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -63,7 +63,7 @@ merge request from the UI, until you make all relevant jobs pass.
 
 When this setting is enabled, a merge request is prevented from being merged if there is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/README.md#onlyexcept-advanced) rules are used and they don't generate any pipelines.
 
-Users that expect to be able to merge a merge request in this scenario should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/issues/54226) and that it's succesful.
+Users that expect to be able to merge a merge request in this scenario should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/issues/54226) and that it's successful.
 
 For example, to that on merge requests there is always a passing job even though `only/except` rules may not generate any other jobs:
 
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index dddabfce4b3..8aa2e0dce37 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -38,7 +38,7 @@ repository. There, you will have full [Owner](../../permissions.md)
 access, so you can set it up as you please.
 
 CAUTION: **CAUTION:**
-From GitLab 12.6 onwards, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
+From GitLab 12.6 onward, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
 in any way, the fork relationship with all its forks will be removed.
 
 CAUTION: **Caution:**
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index 8f2314bf31f..47447e9dad2 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -49,7 +49,7 @@ After making your changes, click the **Commit** button in the bottom left to
 review the list of changed files. If you're using GitLab 12.6 or older versions,
 click on each file to review the changes and tick the item to stage a file.
 
-From [GitLab 12.7 onwards](https://gitlab.com/gitlab-org/gitlab/issues/33441),
+From [GitLab 12.7 onward](https://gitlab.com/gitlab-org/gitlab/issues/33441),
 all your files will be automatically staged. You still have the option to unstage
 changes in case you want to submit them in multiple smaller commits. To unstage
 a change, simply click the **Unstage** button when a staged file is open, or click