Add latest changes from gitlab-org/gitlab@master

8 files changed, 97 insertions, 66 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 d0fb1d85df4..787f1fe6575 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -86,7 +86,8 @@ The first push of a new project, including LFS objects, will be checked for size
 and **will** be rejected if the sum of their sizes exceeds the maximum allowed
 repository size.
 
-**Note:** The repository size limit includes repository files and LFS, and does not include artifacts.
+NOTE: **Note:**
+The repository size limit includes repository files and LFS, and does not include artifacts.
 
 For details on manually purging files, see [reducing the repository size using Git](../../project/repository/reducing_the_repo_size_using_git.md).
 
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 7bc8b62825c..9c0c50c3dd8 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -174,7 +174,7 @@ using environment variables.
 | `CLAIR_DB_IMAGE_TAG`           | (**DEPRECATED - use `CLAIR_DB_IMAGE` instead**) The Docker image tag for the [PostgreSQL server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes.                                                                                                                                                                                                                                                                                                                                                                                                                                   | `latest`                                                                                                        |
 | `DOCKERFILE_PATH`              | The path to the `Dockerfile` to be used for generating remediations. By default, the scanner will look for a file named `Dockerfile` in the root directory of the project, so this variable should only be configured if your `Dockerfile` is in a non-standard location, such as a subdirectory. See [Solutions for vulnerabilities](#solutions-for-vulnerabilities-auto-remediation) for more details.                                                                                                                                                                                                                                                                                                                                                                          | `Dockerfile`                                                                                                    |
 | `ADDITIONAL_CA_CERT_BUNDLE`    | Bundle of CA certs that you want to trust. | "" |
-| `SECURE_LOG_LEVEL`             | The log levels available are: `fatal`, `error`, `warn`, `info`, `debug` | `info` |
+| `SECURE_LOG_LEVEL`             | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. | `info` |
 
 ### Overriding the Container Scanning template
 
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 57b4fae3230..25744253856 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -155,7 +155,7 @@ The following variables allow configuration of global dependency scanning settin
 | `DS_DISABLE_DIND`                       | Disable Docker-in-Docker and run analyzers [individually](#enabling-docker-in-docker). This variable is `true` by default. |
 | `ADDITIONAL_CA_CERT_BUNDLE`             | Bundle of CA certs to trust. |
 | `DS_EXCLUDED_PATHS`                     | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"` |
-| `SECURE_LOG_LEVEL`                      | Default log level is `info`, you can set it to any of the following strings: `fatal`, `error`, `warn`, `info`, `debug`. |
+| `SECURE_LOG_LEVEL`                      | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info` |
 
 #### Configuring Docker-in-Docker orchestrator
 
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 6135c90c9d3..ee9d5eb9348 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -289,14 +289,16 @@ See [Analyzer settings](#analyzer-settings) for the complete list of available o
 
 SAST can be [configured](#customizing-the-sast-settings) using environment variables.
 
-#### Logging Level
+#### Logging level
 
-You can control the verbosity of logs by setting the `SECURE_LOG_LEVEL` env var. The default is set to `info`, you can set it to any of the following levels:
+To control the verbosity of logs set the `SECURE_LOG_LEVEL` environment variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
+
+From highest to lowest severity, the logging levels are:
 
 - `fatal`
 - `error`
 - `warn`
-- `info`
+- `info` (default)
 - `debug`
 
 #### Custom Certificate Authority
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index ea635212c5d..53767ef96b1 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -147,14 +147,16 @@ Secret Detection can be customized by defining available variables:
 | `SECRET_DETECTION_COMMIT_TO` | -       | The commit a Gitleaks scan ends at. |
 | `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
 
-### Logging Level
+### Logging level
 
-You can control the verbosity of logs by setting the `SECURE_LOG_LEVEL` env var. The default is set to `info`, you can set it to any of the following levels:
+To control the verbosity of logs set the `SECURE_LOG_LEVEL` environment variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
+
+From highest to lowest severity, the logging levels are:
 
 - `fatal`
 - `error`
 - `warn`
-- `info`
+- `info` (default)
 - `debug`
 
 ## Full History Secret Scan
diff --git a/doc/user/packages/container_registry/index.md b/doc/user/packages/container_registry/index.md
index 429d29b7677..f8b659aebc1 100644
--- a/doc/user/packages/container_registry/index.md
+++ b/doc/user/packages/container_registry/index.md
@@ -496,81 +496,72 @@ Container Registry.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15398) in GitLab 12.8.
 > - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/218737) from "expiration policy" to "cleanup policy" in GitLab 13.2.
 
-For a specific project, if you want to remove tags you no longer need,
-you can create a cleanup policy. When the policy is applied, tags matching the regex pattern are removed.
+The cleanup policy is a scheduled job you can use to remove tags from the Container Registry.
+For the project where it's defined, tags matching the regex pattern are removed.
 The underlying layers and images remain.
 
-To delete the underlying layers and images no longer associated with any tags, Instance Administrators can use
+To delete the underlying layers and images that aren't associated with any tags, administrators can use
 [garbage collection](../../../administration/packages/container_registry.md#removing-unused-layers-not-referenced-by-manifests) with the `-m` switch.
 
-NOTE: **Note:**
-For GitLab.com, cleanup policies are not available for projects created
-before this feature was deployed to production (February 2020).
-Support for pre-existing projects on GitLab.com
-[is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/196124).
-For self-managed instances, cleanup policies may be enabled by an admin in the
-[GitLab application settings](../../../api/settings.md#change-application-settings) by setting `container_expiration_policies_enable_historic_entries` to true.
-Note the inherent [risks involved](./index.md#use-with-external-container-registries).
-
-The cleanup policy algorithm starts by collecting all the tags for a given repository in a list,
-then goes through a process of excluding tags from it until only the ones to be deleted remain:
-
-1. Collect all the tags for a given repository in a list.
-1. Excludes the tag named `latest` from the list.
-1. Evaluates the `name_regex`, excluding non-matching names from the list.
-1. Excludes any tags that do not have a manifest (not part of the options).
-1. Orders the remaining tags by `created_date`.
-1. Excludes from the list the N tags based on the `keep_n` value (Number of tags to retain).
-1. Excludes from the list the tags more recent than the `older_than` value (Cleanup interval).
-1. Excludes from the list any tags matching the `name_regex_keep` value (Images to preserve).
-1. Finally, the remaining tags in the list are deleted from the Container Registry.
+### Enable the cleanup policy
 
-### Managing project cleanup policy through the UI
+The cleanup policy is enabled for all projects by default.
 
-To manage project cleanup policy, navigate to **{settings}** **Settings > CI/CD > Container Registry tag cleanup policy**.
+- For GitLab.com, the project must have been created before February, 2020.
+  Support for projects created earlier
+  [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/196124).
 
-The UI allows you to configure the following:
+- For self-managed GitLab instances, the project must have been created
+  before GitLab 12.7. However, an administrator can enable the cleanup policy
+  for all projects (even those created before 12.7) in
+  [GitLab application settings](../../../api/settings.md#change-application-settings)
+  by setting `container_expiration_policies_enable_historic_entries` to true.
 
-- **Cleanup policy:** enable or disable the cleanup policy.
-- **Cleanup interval:** how long tags are exempt from being deleted.
-- **Cleanup schedule:** how often the cron job checking the tags should run.
-- **Number of tags to retain:** how many tags to _always_ keep for each image.
-- **Docker tags with names matching this regex pattern will expire:** the regex used to determine what tags should be cleaned up. To qualify all tags for cleanup, use the default value of `.*`.
-- **Docker tags with names matching this regex pattern will be preserved:** the regex used to determine what tags should be preserved. To preserve all tags, use the default value of `.*`.
+  There are performance risks with enabling it for all projects, especially if you
+  are using an [external registry](./index.md#use-with-external-container-registries).
 
-#### Troubleshooting cleanup policies
+### How the cleanup policy works
 
-If you see the following message:
+The cleanup policy collects all tags in the Container Registry and excludes tags
+until only the tags to be deleted remain.
 
-"Something went wrong while updating the cleanup policy."
+The cleanup policy:
 
-Check the regex patterns to ensure they are valid.
+1. Collects all tags for a given repository in a list.
+1. Excludes the tag named `latest` from the list.
+1. Evaluates the `name_regex` (tags to expire), excluding non-matching names from the list.
+1. Excludes any tags that do not have a manifest (not part of the options in the UI).
+1. Orders the remaining tags by `created_date`.
+1. Excludes from the list the N tags based on the `keep_n` value (Number of tags to retain).
+1. Excludes from the list the tags more recent than the `older_than` value (Expiration interval).
+1. Excludes from the list any tags matching the `name_regex_keep` value (tags to preserve).
+1. Finally, the remaining tags in the list are deleted from the Container Registry.
 
-You can use [Rubular](https://rubular.com/) to check your regex.
-View some common [regex pattern examples](#regex-pattern-examples).
+### Create a cleanup policy
 
-### Managing project cleanup policy through the API
+You can create a cleanup policy in [the API](#use-the-cleanup-policy-api) or the UI.
 
-You can set, update, and disable the cleanup policies using the GitLab API.
+To create a cleanup policy in the UI:
 
-Examples:
+1. For your project, go to **Settings > CI/CD**.
+1. Expand the **Cleanup policy for tags** section.
+1. Complete the fields.
 
-- Select all tags, keep at least 1 tag per image, clean up any tag older than 14 days, run once a month, preserve any images with the name `master` and the policy is enabled:
-
-  ```shell
-  curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: <your_access_token>" --data-binary '{"container_expiration_policy_attributes":{"cadence":"1month","enabled":true,"keep_n":1,"older_than":"14d","name_regex":"","name_regex_delete":".*","name_regex_keep":".*-master"}}' 'https://gitlab.example.com/api/v4/projects/2'
-  ```
+   | Field                                                                     | Description                                                                                                       |
+   |---------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
+   | **Cleanup policy**                                                        | Turn the policy on or off.                                                                                        |
+   | **Expiration interval**                                                   | How long tags are exempt from being deleted.                                                                      |
+   | **Expiration schedule**                                                   | How often the policy should run.                                                                                  |
+   | **Number of tags to retain**                                              | How many tags to _always_ keep for each image.                                                                    |
+   | **Tags with names matching this regex pattern will expire:**              | The regex pattern that determines which tags to remove. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
+   | **Tags with names matching this regex pattern will be preserved:**        | The regex pattern that determines which tags to preserve. The `latest` tag is always preserved. For all tags, use `.*`. See other [regex pattern examples](#regex-pattern-examples). |
 
-See the API documentation for further details: [Edit project](../../../api/projects.md#edit-project).
+1. Click **Set cleanup policy**.
 
-### Use with external container registries
+Depending on the interval you chose, the policy is scheduled to run.
 
-When using an [external container registry](./../../../administration/packages/container_registry.md#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint),
-running a cleanup policy on a project may have some performance risks. If a project is going to run
-a policy that will remove large quantities of tags (in the thousands), the GitLab background jobs that
-run the policy may get backed up or fail completely. It is recommended you only enable container cleanup
-policies for projects that were created before GitLab 12.8 if you are confident the amount of tags
-being cleaned up will be minimal.
+NOTE: **Note:**
+If you edit the policy and click **Set cleanup policy** again, the interval is reset.
 
 ### Regex pattern examples
 
@@ -602,6 +593,40 @@ Here are examples of regex patterns you may want to use:
   (?:v.+|master|release)
   ```
 
+### Use the cleanup policy API
+
+You can set, update, and disable the cleanup policies using the GitLab API.
+
+Examples:
+
+- Select all tags, keep at least 1 tag per image, clean up any tag older than 14 days, run once a month, preserve any images with the name `master` and the policy is enabled:
+
+  ```shell
+  curl --request PUT --header 'Content-Type: application/json;charset=UTF-8' --header "PRIVATE-TOKEN: <your_access_token>" --data-binary '{"container_expiration_policy_attributes":{"cadence":"1month","enabled":true,"keep_n":1,"older_than":"14d","name_regex":"","name_regex_delete":".*","name_regex_keep":".*-master"}}' 'https://gitlab.example.com/api/v4/projects/2'
+  ```
+
+See the API documentation for further details: [Edit project](../../../api/projects.md#edit-project).
+
+### Use with external container registries
+
+When using an [external container registry](./../../../administration/packages/container_registry.md#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint),
+running a cleanup policy on a project may have some performance risks. If a project is going to run
+a policy that will remove large quantities of tags (in the thousands), the GitLab background jobs that
+run the policy may get backed up or fail completely. It is recommended you only enable container cleanup
+policies for projects that were created before GitLab 12.8 if you are confident the amount of tags
+being cleaned up will be minimal.
+
+### Troubleshooting cleanup policies
+
+If you see the following message:
+
+"Something went wrong while updating the cleanup policy."
+
+Check the regex patterns to ensure they are valid.
+
+You can use [Rubular](https://rubular.com/) to check your regex.
+View some common [regex pattern examples](#regex-pattern-examples).
+
 ## Use the Container Registry to store Helm Charts
 
 With the launch of [Helm v3](https://helm.sh/docs/topics/registries/),
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index 618506ea7ee..24e0fa00bfd 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -197,7 +197,7 @@ Once selected, click the **Delete selected** button to confirm the deletion:
 
 ![Delete multiple designs](img/delete_multiple_designs_v12_4.png)
 
-**Note:**
+NOTE: **Note:**
 Only the latest version of the designs can be deleted.
 Deleted designs are not permanently lost; they can be
 viewed by browsing previous versions.
diff --git a/doc/user/project/repository/file_finder.md b/doc/user/project/repository/file_finder.md
index ac10071e578..06514c9e850 100644
--- a/doc/user/project/repository/file_finder.md
+++ b/doc/user/project/repository/file_finder.md
@@ -37,6 +37,7 @@ the `app/controllers/admin/deploy_keys_controller.rb` file.
 
 Using a fuzzy search, we start by typing letters that get us closer to the file.
 
-**Tip:** To narrow down your search, include `/` in your search terms.
+TIP: **Tip:**
+To narrow down your search, include `/` in your search terms.
 
 ![Find file button](img/file_finder_find_file_v12_10.png)