Add latest changes from gitlab-org/gitlab@master

6 files changed, 34 insertions, 13 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 5c7a53c3089..d9e07d45355 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -12227,6 +12227,16 @@ The response from the AdminSidekiqQueuesDeleteJobs mutation.
 | <a id="deletejobsresponsedeletedjobs"></a>`deletedJobs` | [`Int`](#int) | Number of matching jobs deleted. |
 | <a id="deletejobsresponsequeuesize"></a>`queueSize` | [`Int`](#int) | Queue size after processing. |
 
+### `DeletedNote`
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="deletednotediscussionid"></a>`discussionId` | [`DiscussionID`](#discussionid) | ID of the discussion for the deleted note. |
+| <a id="deletednoteid"></a>`id` | [`NoteID!`](#noteid) | ID of the deleted note. |
+| <a id="deletednotelastdiscussionnote"></a>`lastDiscussionNote` | [`Boolean`](#boolean) | Whether deleted note is the last note in the discussion. |
+
 ### `DependencyProxyBlob`
 
 Dependency proxy blob.
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index e27d4911158..8672480e993 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -432,6 +432,12 @@ results are available, and not just the first failure.
 
 You must [set feature category metadata for each RSpec example](../feature_categorization/index.md#rspec-examples).
 
+### Tests depending on EE license
+
+You can use `if: Gitlab.ee?` or `unless: Gitlab.ee?` on context/spec blocks to execute tests depending on whether running with `FOSS_ONLY=1`.
+
+Example: [SchemaValidator reads a different path depending on the license](https://gitlab.com/gitlab-org/gitlab/-/blob/7cdcf9819cfa02c701d6fa9f18c1e7a8972884ed/spec/lib/gitlab/ci/parsers/security/validators/schema_validator_spec.rb#L571)
+
 ### Coverage
 
 [`simplecov`](https://github.com/colszowka/simplecov) is used to generate code test coverage reports.
diff --git a/doc/user/group/compliance_frameworks.md b/doc/user/group/compliance_frameworks.md
index 55bcb4ea1fb..a926acf5b08 100644
--- a/doc/user/group/compliance_frameworks.md
+++ b/doc/user/group/compliance_frameworks.md
@@ -26,7 +26,7 @@ Group owners can create, edit, and delete compliance frameworks:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/375036) in GitLab 15.6.
 
 Group owners can set a default compliance framework. The default framework is applied to all the new and imported
-projects that are created within that group. It does not affect the framework applied to the existing projects. The
+projects that are created in that group. It does not affect the framework applied to the existing projects. The
 default framework cannot be deleted.
 
 A compliance framework that is set to default has a **default** label.
@@ -202,7 +202,8 @@ include:  # Execute individual project's configuration (if project contains .git
 When an MR originates in a fork, the branch to be merged usually only exists in the fork.
 When creating such an MR against a project with CF pipelines, the above snippet fails with a
 `Project <project-name> reference <branch-name> does not exist!` error message.
-This is because in the context of the target project, `$CI_COMMIT_REF_NAME` evaluates to a non-existing branch name.
+This error occurs because in the context of the target project, `$CI_COMMIT_REF_NAME` evaluates to a non-existing
+branch name.
 
 To get the correct context, use `$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` instead of `$CI_PROJECT_PATH`.
 This variable is only available in
@@ -241,7 +242,7 @@ Generally, if a value in a compliance job:
 
 Either might be wanted or not depending on your use case.
 
-There are a few best practices for ensuring that these jobs are always run exactly
+The following are a few best practices for ensuring that these jobs are always run exactly
 as you define them and that downstream, project-level pipeline configurations
 cannot change them:
 
@@ -266,7 +267,7 @@ compatibility for combining compliance pipelines, and parent and child pipelines
 Compliance pipelines start on the run of _every_ pipeline in a labeled project. This means that if a pipeline in the labeled project
 triggers a child pipeline, the compliance pipeline runs first. This can trigger the parent pipeline, instead of the child pipeline.
 
-Therefore, in projects with compliance frameworks, we recommend replacing
+Therefore, in projects with compliance frameworks, you should replace
 [parent-child pipelines](../../ci/pipelines/downstream_pipelines.md#parent-child-pipelines) with the following:
 
 - Direct [`include`](../../ci/yaml/index.md#include) statements that provide the parent pipeline with child pipeline configuration.
@@ -279,8 +280,9 @@ This alternative ensures the compliance pipeline does not re-start the parent pi
 
 ### Cannot remove compliance framework from a project
 
-If you move a project, the compliance framework can become orphaned and can't be removed. To manually remove a compliance framework from a project, run the following GraphQL
-mutation with your project's ID:
+Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390626), if you move a project, its compliance
+framework becomes orphaned and can't be removed. To manually remove a compliance framework from a project, run the
+following GraphQL mutation with your project's ID:
 
 ```graphql
 mutation {
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 4eeb2a55189..e23458249f2 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -122,7 +122,8 @@ Create the group you want to import to and connect the source:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/385689) in GitLab 15.8, option to import groups with or without projects.
 
 After you have authorized access to the source GitLab instance, you are redirected to the GitLab group
-importer page. The top-level groups on the connected source instance you have the Owner role for are listed.
+importer page. Here you can see a list of the top-level groups on the connected source instance where you have the Owner
+role.
 
 1. By default, the proposed group namespaces match the names as they exist in source instance, but based on your permissions, you can choose to edit these names before you proceed to import any of them.
 1. Next to the groups you want to import, select either:
diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md
index 9ea78631ee1..24748b2e89c 100644
--- a/doc/user/project/import/index.md
+++ b/doc/user/project/import/index.md
@@ -17,20 +17,22 @@ If you want to bring existing projects to GitLab or copy GitLab projects to a di
 
 Prerequisite:
 
-- At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0.
+- At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was
+  [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0.
 
 For any type of source and target, you can migrate GitLab projects:
 
-- When [migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended), which allows you to migrate all
-  projects in a group at once. Migrating projects by direct transfer is in [Beta](../../../policy/alpha-beta-support.md#beta-features). The feature is not ready
-  for production use.
+- When [migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended),
+  which allows you to migrate all projects in a group simultaneously. Migrating projects by direct transfer is in
+  [Beta](../../../policy/alpha-beta-support.md#beta-features). The feature is not ready for production use.
 - Using [file exports](../settings/import_export.md). With this method you can migrate projects one by one. No network
   connection between instances is required.
 
 If you only need to migrate Git repositories, you can [import each project by URL](repo_by_url.md). However, you can't
 import issues and merge requests this way. To retain metadata like issues and merge requests, either:
 
-- [Migrate projects with groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended). This feature is in [Beta](../../../policy/alpha-beta-support.md#beta-features). It is not ready for production use.
+- [Migrate projects with groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
+  This feature is in [Beta](../../../policy/alpha-beta-support.md#beta-features). It is not ready for production use.
 - Use [file exports](../settings/import_export.md) to import projects.
 
 Keep in mind the limitations of [migrating using file exports](../settings/import_export.md#items-that-are-exported).
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index 2b5f5dfa21d..3715eef08e0 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -14,7 +14,7 @@ then imported into a new GitLab instance. You can also:
 
 GitLab maps user contributions correctly when an admin access token is used to perform the import.
 
-As a result, migrating projects using file exports does not map user contributions correctly when you are importing
+Consequently, migrating projects using file exports does not map user contributions correctly when you are importing
 projects from a self-managed instance to GitLab.com.
 
 Instead, all GitLab user associations (such as comment author) are changed to the user importing the project. For more