Add latest changes from gitlab-org/gitlab@13-8-stable-eev13.8.0-rc42

13 files changed, 131 insertions, 64 deletions

diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md
index 8f629fd4250..80108fba060 100644
--- a/doc/user/admin_area/analytics/dev_ops_report.md
+++ b/doc/user/admin_area/analytics/dev_ops_report.md
@@ -38,7 +38,7 @@ collected before this feature is available.
 
 ## DevOps Adoption **(ULTIMATE)**
 
-[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7.
+[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta).
 
 The DevOps Adoption tab shows you which segments of your organization are using the most essential features of GitLab:
 
@@ -50,7 +50,9 @@ The DevOps Adoption tab shows you which segments of your organization are using
 - Deploys
 - Scanning
 
-Segments are arbitrary collections of GitLab groups that you define. You might define a segment to represent a small team, a large department, or a whole organization. You are limited to creating a maximum of 20 segments, and each segment is limited to a maximum of 20 groups. Buttons to manage your segments appear in the DevOps Adoption section of the page.
+Segments are arbitrary collections of GitLab groups that you define. You might define a segment to represent a small team, a large department, or a whole organization.
+You are limited to creating a maximum of 20 segments, and each segment is limited to a maximum of 20 groups.
+Buttons to manage your segments appear in the DevOps Adoption section of the page.
 
 DevOps Adoption allows you to:
 
@@ -62,18 +64,18 @@ DevOps Adoption allows you to:
 
 ### Disable or enable DevOps Adoption
 
-DevOps Adoption is deployed behind a feature flag that is **enabled by default**.
+DevOps Adoption is deployed behind a feature flag that is **disabled by default**.
 [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can opt to disable it.
+can opt to enable it.
 
-To disable it:
+To enable it:
 
 ```ruby
-Feature.disable(:devops_adoption_feature)
+Feature.enable(:devops_adoption_feature)
 ```
 
-To enable it:
+To disable it:
 
 ```ruby
-Feature.enable(:devops_adoption_feature)
+Feature.disable(:devops_adoption_feature)
 ```
diff --git a/doc/user/admin_area/analytics/user_cohorts.md b/doc/user/admin_area/analytics/user_cohorts.md
index 1d2d0029860..7adc9ad59a5 100644
--- a/doc/user/admin_area/analytics/user_cohorts.md
+++ b/doc/user/admin_area/analytics/user_cohorts.md
@@ -6,32 +6,31 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Cohorts **(CORE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/23361) in GitLab 9.1.
-
 As a benefit of having the [usage ping active](../settings/usage_statistics.md),
-GitLab lets you analyze the users' activities over time of your GitLab installation.
+you can analyze your users' GitLab activities over time.
 
-To see User Cohorts, go to **Admin Area > Analytics > Cohorts**.
+To see user cohorts, go to **Admin Area > Analytics > Cohorts**.
 
 ## Overview
 
-How do we read the user cohorts table? Let's take an example with the following
-user cohorts.
+How do you interpret the user cohorts table? Let's review an example with the
+following user cohorts:
 
 ![User cohort example](img/cohorts_v13_4.png)
 
-For the cohort of March 2020, three users have been added on this server and have
-been active since this month. One month later, in April 2020, two users are
-still active. Five months later (August), we can see that one user from this cohort
-is active, or 33% of the original cohort of three that joined in March.
+For the cohort of March 2020, three users were added to this server and have
+been active since this month. One month later (April 2020), two users are still
+active. Five months later (August 2020), one user from this cohort is still
+active, or 33% of the original cohort of three that joined in March.
 
-The Inactive users column shows the number of users who have been added during
-the month, but who have never actually had any activity in the instance.
+The **Inactive users** column shows the number of users who were added during
+the month, but who never had any activity in the instance.
 
 How do we measure the activity of users? GitLab considers a user active if:
 
 - The user signs in.
 - The user has Git activity (whether push or pull).
-- The user visits pages related to Dashboards, Projects, Issues, and Merge Requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8).
-- The user uses the API
-- The user uses the GraphQL API
+- The user visits pages related to dashboards, projects, issues, or merge
+  requests ([introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54947) in GitLab 11.8).
+- The user uses the API.
+- The user uses the GraphQL API.
diff --git a/doc/user/admin_area/img/license_admin_area.png b/doc/user/admin_area/img/license_admin_area.png
deleted file mode 100644
index b5662b81c5e..00000000000
--- a/doc/user/admin_area/img/license_admin_area.png
+++ /dev/null
diff --git a/doc/user/admin_area/img/license_upload.png b/doc/user/admin_area/img/license_upload.png
deleted file mode 100644
index 29d55175a2d..00000000000
--- a/doc/user/admin_area/img/license_upload.png
+++ /dev/null
diff --git a/doc/user/admin_area/img/license_upload_v13_8.png b/doc/user/admin_area/img/license_upload_v13_8.png
new file mode 100644
index 00000000000..c15bc2bfa02
--- /dev/null
+++ b/doc/user/admin_area/img/license_upload_v13_8.png
diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md
index d7710c362e5..d06b0c844ec 100644
--- a/doc/user/admin_area/license.md
+++ b/doc/user/admin_area/license.md
@@ -32,7 +32,7 @@ is locked.
 
 ## Uploading your license
 
-The very first time you visit your GitLab EE installation signed in as an administrator,
+The first time you visit your GitLab EE installation signed in as an administrator,
 you should see a note urging you to upload a license with a link that takes you
 to **Admin Area > License**.
 
@@ -42,18 +42,21 @@ Otherwise, you can:
 
 1. Navigate to the **License** tab, and click **Upload New License**.
 
-   ![License Admin Area](img/license_admin_area.png)
+   - *If you've received a `.gitlab-license` file:*
+     1. Download the license file to your local machine.
+     1. Select **Upload `.gitlab-license` file**.
+     1. Select **Choose File** and select the license file.
+        In this example the license file is named `GitLab.gitlab-license`.
+     1. Check the **Subscription Agreement** checkbox.
+     1. Select **Upload License**.
 
-   - *If you've received a `.gitlab-license` file,* you should have already downloaded
-     it in your local machine. You can then upload it directly by choosing the
-     license file and clicking the **Upload license** button. In the image below,
-     the selected license file is named `GitLab.gitlab-license`.
+     ![Upload license](img/license_upload_v13_8.png)
 
-     ![Upload license](img/license_upload.png)
-
-   - *If you've received your license as plain text,* select the
-     **Enter license key** option, copy the license, paste it into the **License key**
-     field, and click **Upload license**.
+   - *If you've received your license as plain text:*
+     1. Select **Enter license key**.
+     1. Copy the license and paste it into the **License key** field.
+     1. Check the **Subscription Agreement** checkbox.
+     1. Select **Upload License**.
 
 ## Add your license at install time
 
@@ -120,6 +123,11 @@ You can upload and view more than one license, but only the latest license in th
 range is used as the active license. When you upload a future-dated license, it
 doesn't take effect until its applicable date.
 
+NOTE:
+In GitLab 13.6 and earlier, a notification banner about an expiring license may continue to be displayed even after a new license has been uploaded.
+This happens when the newly uploaded license's start date is in the future and the expiring one is still active.
+The banner disappears after the new license becomes active.
+
 ## Troubleshooting
 
 ### There is no License tab in the Admin Area
diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index bc266216714..028858c96f6 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -7,10 +7,18 @@ type: reference
 
 # Account and limit settings **(CORE ONLY)**
 
+## Default projects limit
+
+You can change the default maximum number of projects that users can create in their personal namespace.
+Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
+You can increase or decrease that `Default projects limit` value.
+
+- If you set `Default projects limit` to 0, users are not allowed to create projects in their users personal namespace. However, projects can still be created within a group.
+
 ## Max attachment size
 
 You can change the maximum file size for attachments in comments and replies in GitLab.
-Navigate to **Admin Area (wrench icon) > Settings > General**, then expand **Account and Limit**.
+Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
 From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`.
 
 NOTE:
@@ -21,13 +29,13 @@ details.
 ## Max push size
 
 You can change the maximum push size for your repository.
-Navigate to **Admin Area (wrench icon) > Settings > General**, then expand **Account and Limit**.
+Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
 From here, you can increase or decrease by changing the value in `Maximum push size (MB)`.
 
 ## Max import size
 
 You can change the maximum file size for imports in GitLab.
-Navigate to **Admin Area (wrench icon) > Settings > General**, then expand **Account and Limit**.
+Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
 From here, you can increase or decrease by changing the value in `Maximum import size (MB)`.
 
 NOTE:
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index ef2eb046c21..6418be13ee9 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -174,7 +174,7 @@ but commented out to help encourage others to add to it in the future. -->
 
 WARNING:
 This feature is being re-evaluated in favor of a different
-[compliance solution](https://gitlab.com/gitlab-org/gitlab/-/issues/34830).
+[compliance solution](https://gitlab.com/groups/gitlab-org/-/epics/3156).
 We recommend that users who haven't yet implemented this feature wait for
 the new solution.
 
@@ -187,6 +187,12 @@ sourced from:
 - The [instance template repository](instance_template_repository.md).
 - GitLab-supplied configuration.
 
+NOTE:
+When you use a configuration defined in an instance template repository,
+nested [`include:`](../../../ci/yaml/README.md#include) keywords
+(including `include:file`, `include:local`, `include:remote`, and `include:template`)
+[do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345).
+
 To set required pipeline configuration:
 
 1. Go to **Admin Area > Settings > CI/CD**.
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index a7641ec22ca..9a661fa9716 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -38,7 +38,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [PlantUML](../../../administration/integration/plantuml.md#gitlab) | Allow rendering of PlantUML diagrams in AsciiDoc and Markdown documents. |
 | [Slack application](../../../user/project/integrations/gitlab_slack_application.md#configuration) **(FREE ONLY)** | Slack integration allows you to interact with GitLab via slash commands in a chat window. This option is only available on GitLab.com, though it may be [available for self-managed instances in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/28164). |
 | [Third party offers](third_party_offers.md) | Control the display of third party offers. |
-| [Snowplow](../../../development/product_analytics/snowplow.md) | Configure the Snowplow integration. |
+| [Snowplow](../../../development/snowplow.md) | Configure the Snowplow integration. |
 | [Google GKE](../../project/clusters/add_gke_clusters.md) | Google GKE integration allows you to provision GKE clusters from GitLab. |
 | [Amazon EKS](../../project/clusters/add_eks_clusters.md) | Amazon EKS integration allows you to provision EKS clusters from GitLab. |
 
diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md
index fe4e84b98ac..adb192f5b4a 100644
--- a/doc/user/admin_area/settings/project_integration_management.md
+++ b/doc/user/admin_area/settings/project_integration_management.md
@@ -51,6 +51,14 @@ is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allo
 administrators to update settings inherited by groups and projects without enabling the
 integration on all non-configured groups and projects by default.
 
+### Remove an instance-level default setting
+
+1. Navigate to **Admin Area > Settings > Integrations**.
+1. Select an integration.
+1. Click **Reset** and confirm.
+
+Resetting an instance-level default setting removes the integration from all projects that have the integration set to use default settings.
+
 ## Manage group-level default settings for a project integration
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6.
@@ -86,6 +94,14 @@ is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allo
 administrators to update settings inherited by subgroups and projects without enabling the
 integration on all non-configured groups and projects by default.
 
+### Remove a group-level default setting
+
+1. Navigate to the group's **Settings > Integrations**.
+1. Select an integration.
+1. Click **Reset** and confirm.
+
+Resetting a group-level default setting removes integrations that use default settings and belong to a project or subgroup of the group.
+
 ## Use instance-level or group-level default settings for a project integration
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level settings.
diff --git a/doc/user/admin_area/settings/protected_paths.md b/doc/user/admin_area/settings/protected_paths.md
index 870735f5be7..a03156511e2 100644
--- a/doc/user/admin_area/settings/protected_paths.md
+++ b/doc/user/admin_area/settings/protected_paths.md
@@ -28,11 +28,7 @@ GitLab rate limits the following paths with Rack Attack by default:
 GitLab responds with HTTP status code `429` to POST requests at protected paths
 that exceed 10 requests per minute per IP address.
 
-This header is included in responses to blocked requests:
-
-```plaintext
-Retry-After: 60
-```
+See [User and IP rate limits](../../admin_area/settings/user_and_ip_rate_limits.md#response-headers) for the headers responded to blocked requests.
 
 For example, the following are limited to a maximum 10 requests per minute:
 
diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index 02b1428177f..06b39d67228 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -61,13 +61,12 @@ sequenceDiagram
 
 ## Usage Ping **(CORE ONLY)**
 
-See [Usage Ping guide](../../../development/product_analytics/usage_ping.md).
+See [Usage Ping guide](../../../development/usage_ping.md).
 
-## Instance-level statistics **(CORE ONLY)**
+## Instance-level analytics availability
 
 After usage ping is enabled, GitLab gathers data from other instances and
-can show [usage statistics](../analytics/index.md)
-of your instance to your admins in **Admin Area > Analytics**.
+enables certain [instance-level analytics features](../analytics/index.md) that are dependent on usage ping.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
index 3f0d75dc682..e2040ef19d6 100644
--- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md
+++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
@@ -20,8 +20,42 @@ IP rate limits**:
 
 These limits are disabled by default.
 
+NOTE:
+By default, all Git operations are first tried unauthenticated. Because of this, HTTP Git operations
+may trigger the rate limits configured for unauthenticated requests.
+
 ![user-and-ip-rate-limits](img/user_and_ip_rate_limits.png)
 
+## Response text
+
+A request that exceeds a rate limit returns a 429 response code and a
+plain-text body, which by default is:
+
+```plaintext
+Retry later
+```
+
+It is possible to customize this response text in the Admin Area.
+
+## Response headers
+
+> [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/731) in GitLab 13.8, the `Rate-Limit` headers. `Retry-After` was introduced in an earlier version.
+
+When a client exceeds the associated rate limit, the following requests are
+blocked. The server may respond with rate-limiting information allowing the
+requester to retry after a specific period of time. These information are
+attached into the response headers.
+
+| Header                | Example                         | Description                                                                                                                                                                                                      |
+|:----------------------|:--------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `RateLimit-Limit`     | `60`                            | The request quota for the client **each minute**. If the rate limit period set in the admin area is different from 1 minute, the value of this header is adjusted to approximately the nearest 60-minute period. |
+| `RateLimit-Name`      | `throttle_authenticated_web`    | Name of the throttle blocking the requests.                                                                                                                                                                      |
+| `RateLimit-Observed`  | `67`                            | Number of requests associated to the client in the time window.                                                                                                                                                  |
+| `RateLimit-Remaining` | `0`                             | Remaining quota in the time window. The result of `RateLimit-Limit` - `RateLimit-Remaining`.                                                                                                                     |
+| `RateLimit-Reset`     | `1609844400`                    | [Unix time](https://en.wikipedia.org/wiki/Unix_time)-formatted time when the request quota is reset.                                                                                                             |
+| `RateLimit-ResetTime` | `Tue, 05 Jan 2021 11:00:00 GMT` | [RFC2616](https://tools.ietf.org/html/rfc2616#section-3.3.1)-formatted date and time when the request quota is reset.                                                                                            |
+| `Retry-After`         | `30`                            | Remaining duration **in seconds** until the quota is reset. This is a [standard HTTP header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After).                                             |
+
 ## Use an HTTP header to bypass rate limiting
 
 > [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/622) in GitLab 13.6.
@@ -47,7 +81,7 @@ GitLab. For example:
      in `/etc/default/gitlab`.
 
 It is important that your load balancer erases or overwrites the bypass
-header on all incoming traffic, because otherwise you must trust your
+header on all incoming traffic. Otherwise, you must trust your
 users to not set that header and bypass the GitLab rate limiter.
 
 Note that the bypass only works if the header is set to `1`.
@@ -59,7 +93,9 @@ are marked with `"throttle_safelist":"throttle_bypass_header"` in
 To disable the bypass mechanism, make sure the environment variable
 `GITLAB_THROTTLE_BYPASS_HEADER` is unset or empty.
 
-## Allowing specific users to bypass authenticated request rate limiting
+## Allow specific users to bypass authenticated request rate limiting
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49127) in GitLab 13.7.
 
 Similarly to the bypass header described above, it is possible to allow
 a certain set of users to bypass the rate limiter. This only applies
@@ -82,13 +118,12 @@ are marked with `"throttle_safelist":"throttle_user_allowlist"` in
 
 At application startup, the allowlist is logged in [`auth.log`](../../../administration/logs.md#authlog).
 
-## Trying out throttling settings before enforcing them
+## Try out throttling settings before enforcing them
 
 > [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/629) in GitLab 13.6.
 
-Trying out throttling settings can be done by setting the
-`GITLAB_THROTTLE_DRY_RUN` environment variable to a comma-separated
-list of throttle names.
+You can try out throttling settings by setting the `GITLAB_THROTTLE_DRY_RUN` environment variable to
+a comma-separated list of throttle names.
 
 The possible names are:
 
@@ -99,21 +134,19 @@ The possible names are:
 - `throttle_authenticated_protected_paths_api`
 - `throttle_authenticated_protected_paths_web`
 
-For example: trying out throttles for all authenticated requests to
-non-protected paths could be done by setting
+For example, to try out throttles for all authenticated requests to
+non-protected paths can be done by setting
 `GITLAB_THROTTLE_DRY_RUN='throttle_authenticated_web,throttle_authenticated_api'`.
 
-To enable the dry-run mode for all throttles, the variable can be set
-to `*`.
+To enable dry run mode for all throttles, the variable can be set to `*`.
 
-Setting a throttle to dry-run mode will log a message to the
-[`auth.log`](../../../administration/logs.md#authlog) when it would
-hit the limit, while letting the request continue as normal. The log
-message will contain an `env` field set to `track`. The `matched`
-field will contain the name of throttle that was hit.
+Setting a throttle to dry run mode logs a message to the
+[`auth.log`](../../../administration/logs.md#authlog) when it would hit the limit, while letting the
+request continue as normal. The log message contains an `env` field set to `track`. The `matched`
+field contains the name of throttle that was hit.
 
 It is important to set the environment variable **before** enabling
-the rate limiting in the settings. The settings in the admin panel
+the rate limiting in the settings. The settings in the Admin Area
 take effect immediately, while setting the environment variable
 requires a restart of all the Puma processes.