Add latest changes from gitlab-org/gitlab@master

6 files changed, 113 insertions, 54 deletions

diff --git a/doc/api/releases/index.md b/doc/api/releases/index.md
index 554ee3b1028..da35caa0811 100644
--- a/doc/api/releases/index.md
+++ b/doc/api/releases/index.md
@@ -228,7 +228,7 @@ GET /projects/:id/releases/:tag_name
 | Attribute     | Type           | Required | Description                                                                         |
 | ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
-| `tag_name`    | string         | yes      | The tag where the release will be created from.                                     |
+| `tag_name`    | string         | yes      | The Git tag the release is associated with.                                         |
 
 Example request:
 
@@ -508,7 +508,7 @@ POST /projects/:id/releases/:tag_name/evidence
 | Attribute     | Type           | Required | Description                                                                         |
 | ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
-| `tag_name`    | string         | yes      | The tag where the release will be created from.                                     |
+| `tag_name`    | string         | yes      | The Git tag the release is associated with.                                         |
 
 Example request:
 
@@ -533,7 +533,7 @@ PUT /projects/:id/releases/:tag_name
 | Attribute     | Type            | Required | Description                                                                                                 |
 | ------------- | --------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
 | `id`          | integer/string  | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                         |
-| `tag_name`    | string          | yes      | The tag where the release will be created from.                                                             |
+| `tag_name`    | string          | yes      | The Git tag the release is associated with.                                                                 |
 | `name`        | string          | no       | The release name.                                                                                           |
 | `description` | string          | no       | The description of the release. You can use [Markdown](../../user/markdown.md).                             |
 | `milestones`  | array of string | no       | The title of each milestone to associate with the release. [GitLab Premium](https://about.gitlab.com/pricing/) customers can specify group milestones. To remove all milestones from the release, specify `[]`. |
@@ -640,7 +640,7 @@ DELETE /projects/:id/releases/:tag_name
 | Attribute     | Type           | Required | Description                                                                         |
 | ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
 | `id`          | integer/string | yes      | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
-| `tag_name`    | string         | yes      | The tag where the release will be created from.                                     |
+| `tag_name`    | string         | yes      | The Git tag the release is associated with.                                         |
 
 Example request:
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 59f9dae660a..2e4049f91af 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -1408,37 +1408,20 @@ Other commonly used variables for `if` clauses:
 
 #### `rules:changes`
 
-To determine if jobs should be added to a pipeline, `rules: changes` clauses check
-the files changed by Git push events.
+`rules:changes` determines whether or not to add jobs to a pipeline by checking for
+changes to specific files.
 
 `rules: changes` works exactly the same way as [`only: changes` and `except: changes`](#onlychangesexceptchanges),
-accepting an array of paths.
-
-It always returns true and adds jobs to the pipeline if there is no Git push event.
-For example, jobs with `rules: changes` always run on scheduled and tag pipelines,
-because they are not associated with a Git push event. Only certain pipelines have
-a Git push event associated with them:
-
-- All pipelines with a `$CI_PIPELINE_SOURCE` of `merge_request` or `external_merge_request`.
-- Branch pipelines, which have the `$CI_COMMIT_BRANCH` variable present and a `$CI_PIPELINE_SOURCE` of `push`.
-
-It's recommended to use it only with branch pipelines or merge request pipelines.
-For example, it's common to use `rules: changes` with one of the following `if` clauses:
-
-- `if: $CI_COMMIT_BRANCH`
-- `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'`
-
-For example:
+accepting an array of paths. It's recommended to only use `rules: changes` with branch
+pipelines or merge request pipelines. For example, it's common to use `rules: changes`
+with merge request pipelines:
 
 ```yaml
-workflow:
-  rules:
-    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
-
 docker build:
   script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
   rules:
-    - changes:
+    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
+      changes:
         - Dockerfile
       when: manual
       allow_failure: true
@@ -1446,14 +1429,29 @@ docker build:
 
 In this example:
 
-- [`workflow: rules`](#workflowrules) allows only pipelines for merge requests for all jobs.
+- If the pipeline is a merge request pipeline, check `Dockerfile` for changes.
 - If `Dockerfile` has changed, add the job to the pipeline as a manual job, and allow the pipeline
   to continue running even if the job is not triggered (`allow_failure: true`).
 - If `Dockerfile` has not changed, do not add job to any pipeline (same as `when: never`).
 
-To implement a rule similar to [`except: changes`](#onlychangesexceptchanges),
+To use `rules: changes` with branch pipelines instead of merge request pipelines,
+change the `if:` clause in the example above to:
+
+```yaml
+rules:
+  - if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH
+```
+
+To implement a rule similar to [`except:changes`](#onlychangesexceptchanges),
 use `when: never`.
 
+CAUTION: **Caution:**
+You can use `rules: changes` with other pipeline types, but it is not recommended
+because `rules: changes` always evaluates to true when there is no Git `push` event.
+Tag pipelines, scheduled pipelines, and so on do **not** have a Git `push` event
+associated with them. A `rules: changes` job is **always** added to those pipeline
+if there is no `if:` statement that limits the job to branch or merge request pipelines.
+
 #### `rules:exists`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4.
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index abdaa681230..78caac0d6d5 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -480,6 +480,21 @@ This makes use of [`Intl.DateTimeFormat`](https://developer.mozilla.org/en-US/do
 
 ## Best practices
 
+### Minimize translation updates
+
+Updates can result in the loss of the translations for this string. To minimize risks,
+avoid changes to strings, unless they:
+
+- Add value to the user.
+- Include extra context for translators.
+
+For example, we should avoid changes like this:
+
+```diff
+- _('Number of things: %{count}') % { count: 10 }
++ n_('Number of things: %d', 10)
+```
+
 ### Keep translations dynamic
 
 There are cases when it makes sense to keep translations together within an array or a hash.
diff --git a/doc/development/product_analytics/usage_ping.md b/doc/development/product_analytics/usage_ping.md
index 44e3c58d165..d4a9ef523b8 100644
--- a/doc/development/product_analytics/usage_ping.md
+++ b/doc/development/product_analytics/usage_ping.md
@@ -422,11 +422,11 @@ w
    api.trackRedisHllUserEvent('my_already_defined_event_name'),
    ```
 
-1. Track event using base module `Gitlab::UsageDataCounters::HLLRedisCounter.track_event(entity_id, event_name)`.
+1. Track event using base module `Gitlab::UsageDataCounters::HLLRedisCounter.track_event(values, event_name)`.
 
    Arguments:
 
-   - `entity_id`: value we count. For example: user_id, visitor_id.
+   - `values`: One value or array of values we count. For example: user_id, visitor_id, user_ids.
    - `event_name`: event name.
 
 1. Get event data using `Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names:, start_date:, end_date)`.
@@ -681,6 +681,50 @@ with any of the other services that are running. That is not how node metrics ar
 always runs as a process alongside other GitLab components on any given node. From Usage Ping's perspective none of the node data would therefore
 appear to be associated to any of the services running, since they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics will appear in Usage Ping.
 
+## Aggregated metrics
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
+> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
+> - It's enabled on GitLab.com.
+
+CAUTION: **Warning:**
+This feature is intended solely for internal GitLab use.
+
+In order to add data for aggregated metrics into Usage Ping payload you should add corresponding definition into  [`aggregated_metrics.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/aggregated_metrics.yml) file. Each aggregate definition includes following parts:
+
+- name: unique name under which aggregate metric will be added to Usage Ping payload
+- operator: operator that defines how aggregated metric data will be counted. Available operators are:
+  - `ANY`: removes duplicates and counts all entries that triggered any of listed events
+- events: list of events names (from [`known_events.yml`](#known-events-in-usage-data-payload)) to aggregate into metric. All events in this list must have the same `redis_slot` and `aggregation` attributes.
+
+Example aggregated metric entry:
+
+```yaml
+- name: example_aggregated_metric
+  operator: ANY
+  events: ['i_search_total', 'i_search_advanced', 'i_search_paid']
+```
+
+Aggregated metrics will be added under `aggregated_metrics` key in both `counts_weekly` and `counts_monthly` top level keys in Usage Ping payload.
+
+```ruby
+{
+  :counts_monthly => {
+    :deployments => 1003,
+    :successful_deployments => 78,
+    :failed_deployments => 275,
+    :packages => 155,
+    :personal_snippets => 2106,
+    :project_snippets => 407,
+    :promoted_issues => 719,
+    :aggregated_metrics => {
+      :example_aggregated_metric => 7
+    },
+    :snippets => 2513
+  }
+}
+```
+
 ## Example Usage Ping payload
 
 The following is example content of the Usage Ping payload.
diff --git a/doc/security/password_length_limits.md b/doc/security/password_length_limits.md
index 38d552229c4..b8d329ab342 100644
--- a/doc/security/password_length_limits.md
+++ b/doc/security/password_length_limits.md
@@ -14,11 +14,31 @@ By default, GitLab supports passwords with:
 
 GitLab administrators can modify password lengths:
 
-- Using configuration file.
-- [From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6, using the GitLab UI.
+- Using the GitLab UI. **[From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6 this is the only available option.**
+- Using configuration file. **Up to GitLab 12.5**.
+
+Changing the minimum or maximum length does not affect existing user passwords. Existing users are
+not asked to reset their password to adhere to the new limits. The new limit restriction applies
+only during new user sign-ups and when an existing user performs a password reset.
+
+## Modify minimum password length using GitLab UI
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
+
+The user password length is set to a minimum of 8 characters by default.
+
+To change the minimum password length using GitLab UI:
+
+1. Go to **Admin Area > Settings**, then select **Sign-up restrictions**.
+
+   ![Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
+
+1. Input a **Minimum password length** value greater than or equal to 8, then select **Save changes**.
 
 ## Modify maximum password length using configuration file
 
+From GitLab 12.6, the minimum password length set in this configuration file is ignored. Minimum password lengths must instead be modified via the [GitLab UI](#modify-minimum-password-length-using-gitlab-ui).
+
 The user password length is set to a maximum of 128 characters by default.
 To change that for installations from source:
 
@@ -42,26 +62,6 @@ To change that for installations from source:
 1. [Restart GitLab](../administration/restart_gitlab.md#installations-from-source)
    for the changes to take effect.
 
-NOTE: **Note:**
-From GitLab 12.6, the minimum password length set in this configuration file will be ignored. Minimum password lengths will now have to be modified via the [GitLab UI](#modify-minimum-password-length-using-gitlab-ui) instead.
-
-## Modify minimum password length using GitLab UI
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
-
-The user password length is set to a minimum of 8 characters by default.
-To change that using GitLab UI:
-
-In **Admin Area > Settings** (`/admin/application_settings/general`), go to the section **Sign-up restrictions**.
-
-[Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
-
-Set the **Minimum password length** to a value greater than or equal to 8 and hit **Save changes** to save the changes.
-
-CAUTION: **Caution:**
-Changing minimum or maximum limit does not affect existing user passwords in any manner. Existing users will not be asked to reset their password to adhere to the new limits.
-The new limit restriction will only apply during new user sign-ups and when an existing user performs a password reset.
-
 <!-- ## Troubleshooting
 
 Include any troubleshooting steps that you can foresee. If you know beforehand what issues
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
index 16006f14579..9373743bf2c 100644
--- a/doc/user/infrastructure/index.md
+++ b/doc/user/infrastructure/index.md
@@ -62,6 +62,8 @@ To get started with a GitLab-managed Terraform State, there are two different op
 - [Use a local machine](#get-started-using-local-development).
 - [Use GitLab CI](#get-started-using-gitlab-ci).
 
+Terraform States can be found by navigating to a Project's **{cloud-gear}** **Operations > Terraform** page.
+
 ## Permissions for using Terraform
 
 In GitLab version 13.1, [Maintainer access](../permissions.md) was required to use a