Add latest changes from gitlab-org/gitlab@master

11 files changed, 116 insertions, 34 deletions

diff --git a/doc/api/draft_notes.md b/doc/api/draft_notes.md
index 423ba2bb31d..f1749346dc2 100644
--- a/doc/api/draft_notes.md
+++ b/doc/api/draft_notes.md
@@ -22,7 +22,7 @@ GET /projects/:id/merge_requests/:merge_request_iid/draft_notes
 | `merge_request_iid` | integer             | yes        | The IID of a project merge request
 
 ```json
-{
+[{
   id: 5,
   author_id: 23,
   merge_request_id: 11,
@@ -43,9 +43,10 @@ GET /projects/:id/merge_requests/:merge_request_iid/draft_notes
     new_line: nil,
     line_range: nil
   }
-}
+}]
 ```
 
 ```shell
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/merge_requests/11/draft_notes"
+curl --header "PRIVATE-TOKEN: <your_access_token>" \
+     "https://gitlab.example.com/api/v4/projects/14/merge_requests/11/draft_notes"
 ```
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index e82b5c71a9b..1dddd44d030 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -3563,6 +3563,33 @@ Input type: `IssueUnlinkAlertInput`
 | <a id="mutationissueunlinkalerterrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationissueunlinkalertissue"></a>`issue` | [`Issue`](#issue) | Issue after mutation. |
 
+### `Mutation.issuesBulkUpdate`
+
+Allows updating several properties for a set of issues. Does nothing if the `bulk_update_issues_mutation` feature flag is disabled.
+
+WARNING:
+**Introduced** in 15.9.
+This feature is in Alpha. It can be changed or removed at any time.
+
+Input type: `IssuesBulkUpdateInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationissuesbulkupdateassigneeids"></a>`assigneeIds` | [`[UserID!]`](#userid) | Global ID array of the users that will be assigned to the given issues. Existing assignees will be replaced with the ones on this list. |
+| <a id="mutationissuesbulkupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationissuesbulkupdateids"></a>`ids` | [`[IssueID!]!`](#issueid) | Global ID array of the issues that will be updated. IDs that the user can't update will be ignored. A max of 100 can be provided. |
+| <a id="mutationissuesbulkupdateparentid"></a>`parentId` | [`IssueParentID!`](#issueparentid) | Global ID of the parent that the bulk update will be scoped to . Example `IssueParentID` are `"gid://gitlab/Project/1"` and `"gid://gitlab/Group/1"`. |
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="mutationissuesbulkupdateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
+| <a id="mutationissuesbulkupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
+| <a id="mutationissuesbulkupdateupdatedissuecount"></a>`updatedIssueCount` | [`Int`](#int) | Number of issues that were successfully updated. |
+
 ### `Mutation.iterationCadenceCreate`
 
 Input type: `IterationCadenceCreateInput`
@@ -14421,6 +14448,22 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="groupprojectswithissuesenabled"></a>`withIssuesEnabled` | [`Boolean`](#boolean) | Return only projects with issues enabled. |
 | <a id="groupprojectswithmergerequestsenabled"></a>`withMergeRequestsEnabled` | [`Boolean`](#boolean) | Return only projects with merge requests enabled. |
 
+##### `Group.releases`
+
+Releases belonging to projects in the group.
+
+Returns [`ReleaseConnection`](#releaseconnection).
+
+This field returns a [connection](#connections). It accepts the
+four standard [pagination arguments](#connection-pagination-arguments):
+`before: String`, `after: String`, `first: Int`, `last: Int`.
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="groupreleasessort"></a>`sort` | [`GroupReleaseSort`](#groupreleasesort) | Sort group releases by given criteria. |
+
 ##### `Group.runners`
 
 Find runners visible to the current user.
@@ -18504,7 +18547,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="projectreleasessort"></a>`sort` | [`ReleaseSort`](#releasesort) | Sort releases by this criteria. |
+| <a id="projectreleasessort"></a>`sort` | [`ReleaseSort`](#releasesort) | Sort releases by given criteria. |
 
 ##### `Project.requirement`
 
@@ -22384,6 +22427,15 @@ User permission on groups.
 | <a id="grouppermissioncreate_projects"></a>`CREATE_PROJECTS` | Groups where the user can create projects. |
 | <a id="grouppermissiontransfer_projects"></a>`TRANSFER_PROJECTS` | Groups where the user can transfer projects to. |
 
+### `GroupReleaseSort`
+
+Values for sorting releases belonging to a group.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="groupreleasesortreleased_at_asc"></a>`RELEASED_AT_ASC` | Released at by ascending order. |
+| <a id="groupreleasesortreleased_at_desc"></a>`RELEASED_AT_DESC` | Released at by descending order. |
+
 ### `HealthStatus`
 
 Health status of an issue or epic.
@@ -24057,6 +24109,12 @@ A `IssueID` is a global ID. It is encoded as a string.
 
 An example `IssueID` is: `"gid://gitlab/Issue/1"`.
 
+### `IssueParentID`
+
+A `IssueParentID` is a global ID. It is encoded as a string.
+
+An example `IssueParentID` is: `"gid://gitlab/IssueParent/1"`.
+
 ### `IterationID`
 
 A `IterationID` is a global ID. It is encoded as a string.
diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md
index a95c47ca4b0..50c49079ce7 100644
--- a/doc/ci/environments/deployment_approvals.md
+++ b/doc/ci/environments/deployment_approvals.md
@@ -139,6 +139,9 @@ Using either the GitLab UI or the API, you can:
 - Approve a deployment to allow it to proceed.
 - Reject a deployment to prevent it.
 
+NOTE:
+GitLab administrators can approve or reject all deployments.
+
 ### Approve or reject a deployment using the UI
 
 Prerequisites:
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 522b8d0af79..657e79267ff 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -699,14 +699,16 @@ You can manually override a deployment's expiration date.
 
 The `auto_stop_in` setting is overwritten and the environment remains active until it's stopped manually.
 
-#### Delete a stopped environment
+### Delete an environment
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20620) in GitLab 12.10.
+Delete an environment when you want to remove it and all its deployments.
 
-You can delete [stopped environments](#stop-an-environment) in the GitLab UI or by using
-[the API](../../api/environments.md#delete-an-environment).
+Prerequisites:
+
+- You must have at least the Developer role.
+- You must [stop](#stop-an-environment) the environment before it can be deleted.
 
-To delete a stopped environment in the GitLab UI:
+To delete an environment:
 
 1. On the top bar, select **Main menu > Projects** and find your project.
 1. On the left sidebar, select **Deployments > Environments**.
@@ -714,18 +716,6 @@ To delete a stopped environment in the GitLab UI:
 1. Next to the environment you want to delete, select **Delete environment**.
 1. On the confirmation dialog box, select **Delete environment**.
 
-#### Delete an active environment without running a stop job
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225794) in GitLab 15.1.
-
-You can delete an active environment without running a stop job.
-This is useful when you have an active environment, but the corresponding `action: stop` job can't run or succeed for some reason.
-
-To delete an active environment:
-
-1. Execute the [Stop an environment API](../../api/environments.md#stop-an-environment) while specifying `force=true`.
-1. Execute the [Delete an environment API](../../api/environments.md#delete-an-environment).
-
 ### Access an environment for preparation or verification purposes
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208655) in GitLab 13.2.
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index 8e8cee302bc..fc49be798ec 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -125,7 +125,7 @@ If the user also has push or merge access to the branch deployed on production,
 they have the following privileges:
 
 - [Stop an environment](index.md#stop-an-environment).
-- [Delete a stopped environment](index.md#delete-a-stopped-environment).
+- [Delete an environment](index.md#delete-an-environment).
 - [Create an environment terminal](index.md#web-terminals-deprecated).
 
 ## Deployment-only access to protected environments
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 8a0b5d5607b..2bb5ab6bca6 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -34,7 +34,7 @@ Kubernetes platform. The largest known GitLab instance is on GitLab.com, which i
 [official GitLab Helm chart](https://docs.gitlab.com/charts/) and the [official Linux package](https://about.gitlab.com/install/).
 
 A typical installation uses NGINX or Apache as a web server to proxy through
-[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) and into the [Puma](https://puma.io)
+[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab/tree/master/workhorse) and into the [Puma](https://puma.io)
 application server. GitLab serves web pages and the [GitLab API](../api/rest/index.md) using the Puma
 application server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent
 database backend for job information, metadata, and incoming jobs.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 398f0c17bac..ee85c34b54d 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -290,6 +290,23 @@ warrant a comment could be:
 
 If there are any projects, snippets, or other assets that are required for a reviewer to validate the solution, ensure they have access to those assets before requesting review.
 
+When assigning reviewers, it can be helpful to:
+
+- Add a comment to the MR indicating which *type* of review you are looking for
+  from that reviewer.
+  - For example, if an MR changes a database query and updates
+    backend code, the MR author first needs a `~backend` review and a `~database`
+    review. While assigning the reviewers, the author adds a comment to the MR
+    letting each reviewer know which domain they should review.
+  - Many GitLab team members are domain experts in more than one area,
+    so without this type of comment it is sometimes ambiguous what type
+    of review they are being asked to provide.
+  - Explicitness around MR review types is efficient for the MR author because
+    they receive the type of review that they are looking for and it is
+    efficient for the MR reviewers because they immediately know which type of review to provide.
+  - [Example 1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75921#note_758161716)
+  - [Example 2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109500#note_1253955051)
+
 Avoid:
 
 - Adding TODO comments (referenced above) directly to the source code unless the reviewer requires
diff --git a/doc/development/feature_categorization/index.md b/doc/development/feature_categorization/index.md
index 26c2c553d59..dad94a2aae2 100644
--- a/doc/development/feature_categorization/index.md
+++ b/doc/development/feature_categorization/index.md
@@ -221,3 +221,8 @@ Additionally, we flag the offenses via `RSpec/MissingFeatureCategory` RuboCop ru
 For Engineering Productivity internal tooling we use `feature_category: :tooling`.
 
 For example in [`spec/tooling/danger/specs_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/tooling/danger/specs_spec.rb#L12).
+
+### Shared feature category
+
+For features that support developers and they are not specific to a product group we use `feature_category: :shared`
+For example [`spec/lib/gitlab/job_waiter_spec.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/lib/gitlab/job_waiter_spec.rb)
diff --git a/doc/development/merge_request_concepts/performance.md b/doc/development/merge_request_concepts/performance.md
index c1bdd45891d..740b8f1607b 100644
--- a/doc/development/merge_request_concepts/performance.md
+++ b/doc/development/merge_request_concepts/performance.md
@@ -15,7 +15,7 @@ with and agreed upon by backend maintainers and performance specialists.
 
 It's also highly recommended that you read the following guides:
 
-- [Performance Guidelines../performance.md)
+- [Performance Guidelines](../performance.md)
 - [Avoiding downtime in migrations](../database/avoiding_downtime_in_migrations.md)
 
 ## Definition
@@ -59,8 +59,8 @@ section below for more information.
 about the impact.
 
 Sometimes it's hard to assess the impact of a merge request. In this case you
-should ask one of the merge request reviewers to review your changes. You can
-find a list of these reviewers at <https://about.gitlab.com/company/team/>. A reviewer
+should ask one of the merge request reviewers to review your changes.
+([A list of reviewers](https://about.gitlab.com/company/team/) is available.) A reviewer
 in turn can request a performance specialist to review the changes.
 
 ## Think outside of the box
@@ -119,7 +119,7 @@ data migration. Migrating millions of rows is always troublesome and
 can have a negative impact on the application.
 
 To better understand how to get help with the query plan reviews
-read this section on [how to prepare the merge request for a database review../database_review.md#how-to-prepare-the-merge-request-for-a-database-review).
+read this section on [how to prepare the merge request for a database review](../database_review.md#how-to-prepare-the-merge-request-for-a-database-review).
 
 ## Query Counts
 
@@ -193,7 +193,12 @@ costly, time-consuming query to the replicas.
 
 ## Use CTEs wisely
 
-Read about [complex queries on the relation object../database/iterating_tables_in_batches.md#complex-queries-on-the-relation-object) for considerations on how to use CTEs. We have found in some situations that CTEs can become problematic in use (similar to the n+1 problem above). In particular, hierarchical recursive CTE queries such as the CTE in [AuthorizedProjectsWorker](https://gitlab.com/gitlab-org/gitlab/-/issues/325688) are very difficult to optimize and don't scale. We should avoid them when implementing new features that require any kind of hierarchical structure.
+Read about [complex queries on the relation object](../database/iterating_tables_in_batches.md#complex-queries-on-the-relation-object)
+for considerations on how to use CTEs. We have found in some situations that CTEs can become
+problematic in use (similar to the n+1 problem above). In particular, hierarchical recursive
+CTE queries such as the CTE in [AuthorizedProjectsWorker](https://gitlab.com/gitlab-org/gitlab/-/issues/325688)
+are very difficult to optimize and don't scale. We should avoid them when implementing new features
+that require any kind of hierarchical structure.
 
 CTEs have been effectively used as an optimization fence in many simpler cases,
 such as this [example](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/43242#note_61416277).
@@ -224,7 +229,7 @@ The total number of the queries (including cached ones) executed by the code mod
 should not increase unless absolutely necessary.
 The number of executed queries (including cached queries) should not depend on
 collection size.
-You can write a test by passing the `skip_cached` variable to [QueryRecorder../database/query_recorder.md) to detect this and prevent regressions.
+You can write a test by passing the `skip_cached` variable to [QueryRecorder](../database/query_recorder.md) to detect this and prevent regressions.
 
 As an example, say you have a CI pipeline. All pipeline builds belong to the same pipeline,
 thus they also belong to the same project (`pipeline.project`):
@@ -312,7 +317,7 @@ This could result in Puma timeout and should be avoided at all cost.
 You should set a reasonable timeout, gracefully handle exceptions and surface the
 errors in UI or logging internally.
 
-Using [`ReactiveCaching`../utilities.md#reactivecaching) is one of the best solutions to fetch external data.
+Using [`ReactiveCaching`](../utilities.md#reactivecaching) is one of the best solutions to fetch external data.
 
 ## Keep database transaction minimal
 
@@ -424,7 +429,7 @@ Take into consideration the following when choosing a pagination strategy:
    The database has to sort and iterate all previous items, and this operation usually
    can result in substantial load put on database.
 
-You can find useful tips related to pagination in the [pagination guidelines../database/pagination_guidelines.md).
+You can find useful tips related to pagination in the [pagination guidelines](../database/pagination_guidelines.md).
 
 ## Badge counters
 
@@ -561,5 +566,5 @@ can time out, which is especially problematic for slow clients. If clients take
 to upload/download the processing slot might be killed due to request processing
 timeout (usually between 30s-60s).
 
-For the above reasons it is required that [Workhorse direct upload../uploads/index.md#direct-upload) is implemented
+For the above reasons it is required that [Workhorse direct upload](../uploads/index.md#direct-upload) is implemented
 for all file uploads and downloads.
diff --git a/doc/user/project/merge_requests/conflicts.md b/doc/user/project/merge_requests/conflicts.md
index 6063d64a721..932eec5e631 100644
--- a/doc/user/project/merge_requests/conflicts.md
+++ b/doc/user/project/merge_requests/conflicts.md
@@ -59,7 +59,8 @@ in the user interface, and you can also resolve conflicts locally through the co
 
 To resolve less-complex conflicts from the GitLab user interface:
 
-1. Go to your merge request.
+1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, select **Merge requests** and find the merge request.
 1. Select **Overview**, and scroll to the merge request reports section.
 1. Find the merge conflicts message, and select **Resolve conflicts**.
    GitLab shows a list of files with merge conflicts. The conflicts are
@@ -83,7 +84,8 @@ Some merge conflicts are more complex, requiring you to manually modify lines to
 resolve their conflicts. Use the merge conflict resolution editor to resolve complex
 conflicts in the GitLab interface:
 
-1. Go to your merge request.
+1. On the top bar, select **Main menu > Projects** and find your project.
+1. On the left sidebar, select **Merge requests** and find the merge request.
 1. Select **Overview**, and scroll to the merge request reports section.
 1. Find the merge conflicts message, and select **Resolve conflicts**.
    GitLab shows a list of files with merge conflicts.
diff --git a/doc/user/todos.md b/doc/user/todos.md
index cb7a7248bb2..50b60dc5b4b 100644
--- a/doc/user/todos.md
+++ b/doc/user/todos.md
@@ -130,6 +130,7 @@ To-do items are marked as done if you:
 - Create a comment.
 - Edit the description.
 - Resolve a [design discussion thread](project/issues/design_management.md#resolve-a-discussion-thread-on-a-design).
+- Accept or deny a project or group membership request.
 
 To-do items are **not** marked as done if you: