Add latest changes from gitlab-org/gitlab@master

11 files changed, 70 insertions, 11 deletions

diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index 1674cce1390..b4df6446835 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -58,6 +58,8 @@ Include the code block in the `/etc/gitlab/gitlab.rb` file:
    gitlab_rails['omniauth_providers'] = [
      {
        "name" => "cognito",
+       # "label" => "Cognito",
+       # "icon" => nil,   # Optional icon URL
        "app_id" => "CLIENT ID",
        "app_secret" => "CLIENT SECRET",
        "args" => {
@@ -86,3 +88,5 @@ Include the code block in the `/etc/gitlab/gitlab.rb` file:
 Your sign-in page should now display a Cognito button below the regular sign-in form.
 To begin the authentication process, click the icon, and AWS Cognito will ask the user to sign in and authorize the GitLab application.
 If successful, the user will be redirected and signed in to your GitLab instance.
+
+For more information, see the [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration).
diff --git a/doc/development/database/strings_and_the_text_data_type.md b/doc/development/database/strings_and_the_text_data_type.md
index 8038663392f..0e77e3972e0 100644
--- a/doc/development/database/strings_and_the_text_data_type.md
+++ b/doc/development/database/strings_and_the_text_data_type.md
@@ -276,7 +276,7 @@ end
 
 ## Text limit constraints on large tables
 
-If you have to clean up a text column for a really [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/migration_helpers.rb#L12)
+If you have to clean up a text column for a really [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3)
 (for example, the `artifacts` in `ci_builds`), your background migration will go on for a while and
 it will need an additional [background migration cleaning up](../background_migrations.md#cleaning-up)
 in the release after adding the data migration.
diff --git a/doc/development/database_review.md b/doc/development/database_review.md
index 3927f0c2669..5405a8808f0 100644
--- a/doc/development/database_review.md
+++ b/doc/development/database_review.md
@@ -81,9 +81,9 @@ the following preparations into account.
   - Ensure the down method reverts the changes in `db/structure.sql`.
   - Update the migration output whenever you modify the migrations during the review process.
 - Add tests for the migration in `spec/migrations` if necessary. See [Testing Rails migrations at GitLab](testing_guide/testing_migrations_guide.md) for more details.
-- When [high-traffic](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/migration_helpers.rb#L12) tables are involved in the migration, use the [`with_lock_retries`](migration_style_guide.md#retry-mechanism-when-acquiring-database-locks) helper method. Review the relevant [examples in our documentation](migration_style_guide.md#examples) for use cases and solutions.
+- When [high-traffic](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3) tables are involved in the migration, use the [`with_lock_retries`](migration_style_guide.md#retry-mechanism-when-acquiring-database-locks) helper method. Review the relevant [examples in our documentation](migration_style_guide.md#examples) for use cases and solutions.
 - Ensure RuboCop checks are not disabled unless there's a valid reason to.
-- When adding an index to a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/migration_helpers.rb#L9),
+- When adding an index to a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3),
 test its execution using `CREATE INDEX CONCURRENTLY` in the `#database-lab` Slack channel and add the execution time to the MR description:
   - Execution time largely varies between `#database-lab` and GitLab.com, but an elevated execution time from `#database-lab`
     can give a hint that the execution on GitLab.com will also be considerably high.
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 74c03ec72b4..7d3d9dac174 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -569,7 +569,7 @@ has been deprecated and will be removed in a later release.
 
 NOTE: **Note:**
 If a backport adding a column with a default value is needed for %12.9 or earlier versions,
-it should use `add_column_with_default` helper. If a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/migration_helpers.rb#L12)
+it should use `add_column_with_default` helper. If a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3)
 is involved, backporting to %12.9 is contraindicated.
 
 ## Changing the column default
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index 9fd3097091a..05b80cdb4a6 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -397,7 +397,6 @@ Consult the [Review Apps](testing_guide/review_apps.md) dedicated page for more
 The `* as-if-foss` jobs allows to run GitLab's test suite "as-if-FOSS", meaning as if the jobs would run in the context
 of the `gitlab-org/gitlab-foss` project. These jobs are only created in the following cases:
 
-- `master` commits (pushes and scheduled pipelines).
 - `gitlab-org/security/gitlab` merge requests.
 - Merge requests which include `RUN AS-IF-FOSS` in their title.
 - Merge requests that changes the CI configuration.
diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md
index 858de8e7e36..407899b23d5 100644
--- a/doc/development/what_requires_downtime.md
+++ b/doc/development/what_requires_downtime.md
@@ -130,7 +130,7 @@ class CleanupUsersUpdatedAtRename < ActiveRecord::Migration[4.2]
 end
 ```
 
-NOTE: **Note:** If you're renaming a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/migration_helpers.rb#L9), please carefully consider the state when the first migration has run but the second cleanup migration hasn't been run yet.
+NOTE: **Note:** If you're renaming a [large table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3), please carefully consider the state when the first migration has run but the second cleanup migration hasn't been run yet.
 With [Canary](https://about.gitlab.com/handbook/engineering/infrastructure/library/canary/) it is possible that the system runs in this state for a significant amount of time.
 
 ## Changing Column Constraints
diff --git a/doc/user/project/operations/alert_management.md b/doc/user/project/operations/alert_management.md
index 7aaebd0da08..0d1d725692c 100644
--- a/doc/user/project/operations/alert_management.md
+++ b/doc/user/project/operations/alert_management.md
@@ -92,3 +92,54 @@ alert by clicking the **View Issue** button.
 
 Closing a GitLab issue associated with an alert changes the alert's status to Resolved.
 See [Alert Management statuses](#alert-management-statuses) for more details about statuses.
+
+### Update an Alert's assignee
+
+NOTE: **Note:**
+We currently only support a single assignee per alert.
+
+The Alert Management detail view allows users to update the Alert Assignee(s).
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3066) in GitLab 13.1.
+
+In large teams, where there is shared ownership of an alert, it can be difficult
+to track who is investigating and working on it. The Alert Management detail view
+enables you to update the Alert Assignee(s):
+
+NOTE: **Note:**
+GitLab currently only supports a single assignee per alert.
+
+1. To display the list of current alerts, click
+   **{cloud-gear}** **Operations > Alerts**:
+
+   ![Alert Management List View Assignee(s)](img/alert_list_assignees_v13_1.png)
+
+1. Select your desired alert to display its **Alert Management Details View**:
+
+   ![Alert Management Details View Assignee(s)](img/alert_details_assignees_v13_1.png)
+
+1. If the right sidebar is not expanded, click
+   **{angle-double-right}** **Expand sidebar** to expand it.
+1. In the right sidebar, locate the **Assignee** and click **Edit**. From the
+   dropdown menu, select each user you want to assign to the alert. GitLab creates
+   a [To-Do list item](../../todos.md) for each user.
+
+   ![Alert Management Details View Assignee(s)](img/alert_todo_assignees_v13_1.png)
+
+To remove an assignee, click **Edit** next to the **Assignee** dropdown menu and
+deselect the user from the list of assignees, or click **Unassigned**.
+
+## Use cases for assigning alerts
+
+Consider a team formed by different sections of monitoring, collaborating on a
+single application. After an alert surfaces, it's extremely important to
+route the alert to the team members who can address and resolve the alert.
+
+Assigning Alerts to multiple assignees eases collaboration and delegation. All
+assignees are shown in your team's workflows, and all assignees receive
+notifications, simplifying communication and ownership of the alert.
+
+After completing their portion of investigating or fixing the alert, users can
+unassign their account from the alert when their role is complete.
+The [alerts status](#alert-management-statuses) can be updated to
+reflect if the alert has been resolved.
diff --git a/doc/user/project/operations/img/alert_details_assignees_v13_1.png b/doc/user/project/operations/img/alert_details_assignees_v13_1.png
new file mode 100644
index 00000000000..dab4eac384a
--- /dev/null
+++ b/doc/user/project/operations/img/alert_details_assignees_v13_1.png
diff --git a/doc/user/project/operations/img/alert_list_assignees_v13_1.png b/doc/user/project/operations/img/alert_list_assignees_v13_1.png
new file mode 100644
index 00000000000..db1e0d8dcb7
--- /dev/null
+++ b/doc/user/project/operations/img/alert_list_assignees_v13_1.png
diff --git a/doc/user/project/operations/img/alert_todo_assignees_v13_1.png b/doc/user/project/operations/img/alert_todo_assignees_v13_1.png
new file mode 100644
index 00000000000..637f8be5d25
--- /dev/null
+++ b/doc/user/project/operations/img/alert_todo_assignees_v13_1.png
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index c809b97abf6..58d143fb32b 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -269,11 +269,16 @@ Here is an example of a Release Evidence object:
 {
   "release": {
     "id": 5,
-    "tag": "v4.0",
+    "tag_name": "v4.0",
     "name": "New release",
-    "project_id": 45,
-    "project_name": "Project name",
-    "released_at": "2019-06-28 13:23:40 UTC",
+    "project": {
+      "id": 20,
+      "name": "Project name",
+      "created_at": "2019-04-14T11:12:13.940Z",
+      "description": "Project description"
+    },
+    "created_at": "2019-06-28 13:23:40 UTC",
+    "description": "Release description",
     "milestones": [
       {
         "id": 11,
@@ -313,7 +318,7 @@ Here is an example of a Release Evidence object:
 }
 ```
 
-### Enabling Release Evidence display **(CORE ONLY)**
+### Diabling Release Evidence display **(CORE ONLY)**
 
 This feature comes with the `:release_evidence_collection` feature flag
 enabled by default in GitLab self-managed instances. To turn it off,