Add latest changes from gitlab-org/gitlab@13-10-stable-eev13.10.0-rc40

10 files changed, 64 insertions, 34 deletions

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 70416c224c7..0f391118215 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -152,20 +152,20 @@ To set a limit on how long these sessions are valid:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab Ultimate 12.6.
 
-Users can optionally specify an expiration date for
+Users can optionally specify a lifetime for
 [personal access tokens](../../profile/personal_access_tokens.md).
-This expiration date is not a requirement, and can be set to any arbitrary date.
+This lifetime is not a requirement, and can be set to any arbitrary number of days.
 
 Personal access tokens are the only tokens needed for programmatic access to GitLab.
 However, organizations with security requirements may want to enforce more protection by
 requiring the regular rotation of these tokens.
 
-### Setting a limit
+### Setting a lifetime
 
-Only a GitLab administrator can set a limit. Leaving it empty means
+Only a GitLab administrator can set a lifetime. Leaving it empty means
 there are no restrictions.
 
-To set a limit on how long personal access tokens are valid:
+To set a lifetime on how long personal access tokens are valid:
 
 1. Navigate to **Admin Area > Settings > General**.
 1. Expand the **Account and limit** section.
@@ -180,24 +180,28 @@ Once a lifetime for personal access tokens is set, GitLab:
   allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
   or remove it, before revocation takes place.
 
-## Enforcement of SSH key expiration **(ULTIMATE SELF)**
+## Optional enforcement of SSH key expiration **(ULTIMATE SELF)**
 
-GitLab administrators can choose to enforce the expiration of SSH keys after their expiration dates.
-If you enable this feature, this disables all _expired_ SSH keys.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250480) in GitLab 13.9.
 
-To do this:
+By default, expired SSH keys **can still be used**.
+You can prevent the use of expired SSH keys with the following steps:
 
 1. Navigate to **Admin Area > Settings > General**.
 1. Expand the **Account and limit** section.
 1. Select the **Enforce SSH key expiration** checkbox.
 
-## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)**
+Enforcing SSH key expiration immediately disables all expired SSH keys.
+
+For more information, see the following issue on [SSH key expiration](https://gitlab.com/gitlab-org/gitlab/-/issues/320970).
+
+## Optional non-enforcement of Personal Access Token expiration **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/296881) in GitLab 13.9.
 
-GitLab administrators can choose to prevent personal access tokens from expiring
-automatically. The tokens are usable after the expiry date, unless they are revoked explicitly.
+By default, expired personal access tokens (PATs) cannot be used.
+You can allow the use of expired PATs with the following steps:
 
 To do this:
 
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 761fc6477d6..3d19bde9a26 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -27,7 +27,7 @@ From now on, every existing project and newly created ones that don't have a
 `.gitlab-ci.yml`, will use the Auto DevOps pipelines.
 
 If you want to disable it for a specific project, you can do so in
-[its settings](../../../topics/autodevops/index.md#enablingdisabling-auto-devops).
+[its settings](../../../topics/autodevops/index.md#enable-or-disable-auto-devops).
 
 ## Maximum artifacts size **(FREE SELF)**
 
@@ -50,15 +50,15 @@ To change it at the:
    1. Change the value of maximum artifacts size (in MB).
    1. Click **Save changes** for the changes to take effect.
 
-- [Group level](../../group/index.md#group-settings) (this will override the instance setting):
+- Group level (this will override the instance setting):
 
-  1. Go to the group's **Settings > CI / CD > General Pipelines**.
+  1. Go to the group's **Settings > CI/CD > General Pipelines**.
   1. Change the value of **maximum artifacts size (in MB)**.
   1. Click **Save changes** for the changes to take effect.
 
-- [Project level](../../../ci/pipelines/settings.md) (this will override the instance and group settings):
+- Project level (this will override the instance and group settings):
 
-  1. Go to the project's **Settings > CI / CD > General Pipelines**.
+  1. Go to the project's **Settings > CI/CD > General Pipelines**.
   1. Change the value of **maximum artifacts size (in MB)**.
   1. Click **Save changes** for the changes to take effect.
 
@@ -99,6 +99,13 @@ are allowed to expire.
 This setting takes precedence over the [project level setting](../../../ci/pipelines/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
 If disabled at the instance level, you cannot enable this per-project.
 
+To disable the setting:
+
+1. Go to **Admin Area > Settings > CI/CD**.
+1. Expand **Continuous Integration and Deployment**.
+1. Clear the **Keep the latest artifacts for all jobs in the latest successful pipelines** checkbox.
+1. Click **Save changes**
+
 When you disable the feature, the latest artifacts do not immediately expire.
 A new pipeline must run before the latest artifacts can expire and be deleted.
 
diff --git a/doc/user/admin_area/settings/email.md b/doc/user/admin_area/settings/email.md
index 2eaff417ba3..5deb71698ff 100644
--- a/doc/user/admin_area/settings/email.md
+++ b/doc/user/admin_area/settings/email.md
@@ -29,7 +29,7 @@ legal/auditing/compliance reasons.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22560) in GitLab 11.5.
 
-This configuration option sets the email hostname for [private commit emails](../../profile/index.md#private-commit-email).
+This configuration option sets the email hostname for [private commit emails](../../profile/index.md#use-an-automatically-generated-private-commit-email).
  By default it is set to `users.noreply.YOUR_CONFIGURED_HOSTNAME`.
 
 In order to change this option:
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index 3377b1674db..cbdc617d7d9 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -35,7 +35,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | ------ | ----------- |
 | [Elasticsearch](../../../integration/elasticsearch.md#enabling-advanced-search) | Elasticsearch integration. Elasticsearch AWS IAM. |
 | [Kroki](../../../administration/integration/kroki.md#enable-kroki-in-gitlab) | Allow rendering of diagrams in AsciiDoc and Markdown documents using [kroki.io](https://kroki.io). |
-| [PlantUML](../../../administration/integration/plantuml.md#gitlab) | Allow rendering of PlantUML diagrams in AsciiDoc and Markdown documents. |
+| [PlantUML](../../../administration/integration/plantuml.md) | Allow rendering of PlantUML diagrams in documents. |
 | [Slack application](../../../user/project/integrations/gitlab_slack_application.md#configuration) **(FREE SAAS)** | 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/snowplow.md) | Configure the Snowplow integration. |
diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md
index 7630f0c2fbd..600d99934aa 100644
--- a/doc/user/admin_area/settings/instance_template_repository.md
+++ b/doc/user/admin_area/settings/instance_template_repository.md
@@ -5,9 +5,9 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Instance template repository **(PREMIUM SELF)** **(FREE)**
+# Instance template repository **(PREMIUM SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in GitLab Premium 11.3.
 
 In hosted systems, enterprises often have a need to share their own templates
 across teams. This feature allows an administrator to pick a project to be the
@@ -23,7 +23,7 @@ select the project to serve as the custom template repository.
 ![File templates in the Admin Area](img/file_template_admin_area.png)
 
 After that, you can add custom templates to the selected repository and use them for the entire instance.
-They will be available on the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns)
+They are available in the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns)
 and through the [API settings](../../../api/settings.md).
 
 Templates must be added to a specific subdirectory in the repository,
@@ -60,12 +60,12 @@ extension and not be empty. So, the hierarchy should look like this:
     |-- another_metrics-dashboard.yml
 ```
 
-Your custom templates will be displayed on the dropdown menu when a new file is added through the GitLab UI:
+Your custom templates are displayed on the dropdown menu when a new file is added through the GitLab UI:
 
 ![Custom template dropdown menu](img/file_template_user_dropdown.png)
 
-If this feature is disabled or no templates are present, there will be
-no "Custom" section in the selection dropdown.
+If this feature is disabled or no templates are present,
+no **Custom** section displays in the selection dropdown.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md
index 18491f92650..0b9f039880a 100644
--- a/doc/user/admin_area/settings/project_integration_management.md
+++ b/doc/user/admin_area/settings/project_integration_management.md
@@ -4,7 +4,7 @@ group: Ecosystem
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Project integration management
+# Project integration management **(FREE)**
 
 Project integrations can be configured and enabled by project administrators. As a GitLab instance
 administrator, you can set default configuration parameters for a given integration that all projects
diff --git a/doc/user/admin_area/settings/push_event_activities_limit.md b/doc/user/admin_area/settings/push_event_activities_limit.md
index 1d6424face0..7032c1031a9 100644
--- a/doc/user/admin_area/settings/push_event_activities_limit.md
+++ b/doc/user/admin_area/settings/push_event_activities_limit.md
@@ -14,7 +14,7 @@ allowed at once. If the number of events is greater than this, GitLab creates
 bulk push event instead.
 
 For example, if 4 branches are pushed and the limit is currently set to 3,
-you'll see the following in the activity feed:
+the activity feed displays:
 
 ![Bulk push event](img/bulk_push_event_v12_4.png)
 
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index 0945471b11b..0078db286a8 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -30,7 +30,7 @@ To disable sign ups:
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4491) in GitLab 13.5.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/267568) in GitLab 13.6.
 
-When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approving-a-user) by an administrator before they can start using their account. This setting is enabled by default for newly created instances. This setting is only applicable if sign ups are enabled.
+When this setting is enabled, any user visiting your GitLab domain and signing up for a new account must be explicitly [approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using their account. In GitLab 13.6 and later, this setting is enabled by default for new GitLab instances. It is only applicable if sign ups are enabled.
 
 To require administrator approval for new sign ups:
 
@@ -56,10 +56,29 @@ To enforce confirmation of the email address used for new sign ups:
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
 
 When the number of billable users reaches the user cap, any user who is added or requests access must be
-[approved](../approving_users.md#approving-a-user) by an administrator before they can start using
+[approved](../approving_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
 their account.
 
-If an administrator increases or removes the user cap, the users in pending approval state are
+If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
+user cap, the users in pending approval state are automatically approved in a background job.
+
+### Set the user cap number
+
+1. Go to  **Admin Area > Settings > General**.
+1. Expand **Sign-up restrictions**.
+1. Enter a number in **User cap**.
+1. Select **Save changes**.
+
+New user sign ups are subject to the user cap restriction.
+
+## Remove the user cap
+
+1. Go to  **Admin Area > Settings > General**.
+1. Expand **Sign-up restrictions**.
+1. Remove the number from **User cap**.
+1. Select **Save changes**.
+
+New users sign ups are not subject to the user cap restriction. Users in pending approval state are
 automatically approved in a background job.
 
 ## Soft email confirmation
diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index 2bb6adbc32b..ada44115cec 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -61,7 +61,7 @@ sequenceDiagram
 
 ## Usage Ping **(FREE SELF)**
 
-See [Usage Ping guide](../../../development/usage_ping.md).
+See [Usage Ping guide](../../../development/usage_ping/index.md).
 
 ## Instance-level analytics availability
 
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index 0fcdbf3ca90..e335a9031d5 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -29,7 +29,7 @@ To change the default branch protection:
 
 For more details, see [Protected branches](../../project/protected_branches.md).
 
-To change this setting for a specific group, see [Default branch protection for groups](../../group/index.md#changing-the-default-branch-protection-of-a-group)
+To change this setting for a specific group, see [Default branch protection for groups](../../group/index.md#change-the-default-branch-protection-of-a-group)
 
 ### Disable group owners from updating default branch protection **(PREMIUM SELF)**
 
@@ -55,7 +55,7 @@ To change the default project creation protection:
 1. Select the desired option.
 1. Click **Save changes**.
 
-For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level).
+For more details, see [Specify who can add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group).
 
 ## Default project deletion protection **(PREMIUM SELF)**
 
@@ -79,7 +79,7 @@ The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org
 [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
 
 Projects in a group (but not a personal namespace) can be deleted after a delayed period, by
-[configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
+[configuring in Group Settings](../../group/index.md#enable-delayed-project-removal).
 The default period is seven days, and can be changed. Setting this period to `0` enables immediate removal
 of projects or groups.