Add latest changes from gitlab-org/gitlab@master

23 files changed, 292 insertions, 115 deletions

diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index d873ea14372..731b5012663 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -105,7 +105,10 @@ gitlab:
 
 ## Geo proxying with Separate URLs
 
-Since GitLab 15.1, Geo secondary proxying is enabled by default for separate URLs also.
+> Geo secondary proxying for separate URLs is [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/346112) in GitLab 15.1.
+
+NOTE:
+The feature flag described in this section is planned to be deprecated and removed in a future release. Support for read-only Geo secondary sites is proposed in [issue 366810](https://gitlab.com/gitlab-org/gitlab/-/issues/366810), you can upvote and share your use cases in that issue.
 
 There are minor known issues linked in the
 ["Geo secondary proxying with separate URLs" epic](https://gitlab.com/groups/gitlab-org/-/epics/6865).
diff --git a/doc/administration/inactive_project_deletion.md b/doc/administration/inactive_project_deletion.md
index 224b52d420e..ed46996143e 100644
--- a/doc/administration/inactive_project_deletion.md
+++ b/doc/administration/inactive_project_deletion.md
@@ -6,18 +6,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Inactive project deletion **(FREE SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689) in GitLab 15.0 [with a flag](../administration/feature_flags.md) named `inactive_projects_deletion`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to
-[enable the feature flag](../administration/feature_flags.md) named `inactive_projects_deletion`.
-On GitLab.com, this feature is not available. This feature is not ready for production use.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689) in GitLab 15.0 [with a flag](../administration/feature_flags.md) named `inactive_projects_deletion`. Disabled by default.
+> - [Feature flag `inactive_projects_deletion`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96803) removed in GitLab 15.4.
 
 Administrators of large GitLab instances can find that over time, projects become inactive and are no longer used.
 These projects take up unnecessary disk space. With inactive project deletion, you can identify these projects, warn
 the maintainers ahead of time, and then delete the projects if they remain inactive. When an inactive project is
 deleted, the action generates an audit event that it was performed by the first active administrator.
 
+For the default setting on GitLab.com, see the [GitLab.com settings page](../user/gitlab_com/index.md#inactive-project-deletion).
+
 ## Configure inactive project deletion
 
 You can configure inactive projects deletion or turn it off using either:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 87900d1451b..d7e3ae81ad0 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -11536,12 +11536,19 @@ Describes where code is deployed for a project.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="environmentautodeleteat"></a>`autoDeleteAt` | [`Time`](#time) | When the environment is going to be deleted automatically. |
+| <a id="environmentautostopat"></a>`autoStopAt` | [`Time`](#time) | When the environment is going to be stopped automatically. |
+| <a id="environmentcreatedat"></a>`createdAt` | [`Time`](#time) | When the environment was created. |
+| <a id="environmentenvironmenttype"></a>`environmentType` | [`String`](#string) | Folder name of the environment. |
 | <a id="environmentexternalurl"></a>`externalUrl` | [`String`](#string) | External URL of the environment. |
 | <a id="environmentid"></a>`id` | [`ID!`](#id) | ID of the environment. |
 | <a id="environmentlatestopenedmostseverealert"></a>`latestOpenedMostSevereAlert` | [`AlertManagementAlert`](#alertmanagementalert) | Most severe open alert for the environment. If multiple alerts have equal severity, the most recent is returned. |
 | <a id="environmentname"></a>`name` | [`String!`](#string) | Human-readable name of the environment. |
 | <a id="environmentpath"></a>`path` | [`String!`](#string) | Path to the environment. |
+| <a id="environmentslug"></a>`slug` | [`String`](#string) | Slug of the environment. |
 | <a id="environmentstate"></a>`state` | [`String!`](#string) | State of the environment, for example: available/stopped. |
+| <a id="environmenttier"></a>`tier` | [`DeploymentTier`](#deploymenttier) | Deployment tier of the environment. |
+| <a id="environmentupdatedat"></a>`updatedAt` | [`Time`](#time) | When the environment was updated. |
 
 #### Fields with arguments
 
diff --git a/doc/api/settings.md b/doc/api/settings.md
index 5e1be5bce51..c3578f53c32 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -286,7 +286,7 @@ listed in the descriptions of the relevant settings.
 | `default_snippet_visibility`             | string           | no                                   | What visibility level new snippets receive. Can take `private`, `internal` and `public` as a parameter. Default is `private`. |
 | `delayed_project_deletion` **(PREMIUM SELF)** | boolean     | no                                   | Enable delayed project deletion by default in new groups. Default is `false`. [From GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/352960), can only be enabled when `delayed_group_deletion` is true. |
 | `delayed_group_deletion` **(PREMIUM SELF)**   | boolean     | no                                   | Enable delayed group deletion. Default is `true`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352959) in GitLab 15.0. [From GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/352960), disables and locks the group-level setting for delayed protect deletion when set to `false`.  |
-| `delete_inactive_projects`               | boolean          | no                                   | Enable inactive project deletion feature. Default is `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84519) in GitLab 14.10. [Became operational](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689) in GitLab 15.0 (with feature flag `inactive_projects_deletion`, disabled by default). |
+| `delete_inactive_projects`               | boolean          | no                                   | Enable inactive project deletion feature. Default is `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84519) in GitLab 14.10. [Became operational without feature flag](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96803) in GitLab 15.4. |
 | `deletion_adjourned_period` **(PREMIUM SELF)** | integer    | no                                   | The number of days to wait before deleting a project or group that is marked for deletion. Value must be between `1` and `90`. Defaults to `7`. [From GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/352960), a hook on `deletion_adjourned_period` sets the period to `1` on every update, and sets both `delayed_project_deletion` and `delayed_group_deletion` to `false` if the period is `0`. |
 | `diff_max_patch_bytes`                   | integer          | no                                   | Maximum [diff patch size](../user/admin_area/diff_limits.md), in bytes. |
 | `diff_max_files`                         | integer          | no                                   | Maximum [files in a diff](../user/admin_area/diff_limits.md). |
diff --git a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
index 4e3abcdae09..a70a01031a7 100644
--- a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
+++ b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md
@@ -79,7 +79,7 @@ cannot be cleaned by `autovacuum`. This highlight the need for small tables.
 We will measure how much bloat we accumulate when [re]indexing huge tables. Base on this analysis,
 we will be able to set up SLO (dead tuples / bloat), associated with [re]indexing.
 
-We’ve seen numerous S1 and S2 database-related production environment
+We've seen numerous S1 and S2 database-related production environment
 incidents, over the last couple of months, for example:
 
 - S1: 2022-03-17 [Increase in writes in `ci_builds` table](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6625)
@@ -135,7 +135,7 @@ remaining database tables when it becomes necessary.
 It is also important to avoid large data migrations. We store almost 6
 terabytes of data in the biggest CI/CD tables, in many different columns and
 indexes. Migrating this amount of data might be challenging and could cause
-instability in the production environment. Due to this concern, we’ve developed
+instability in the production environment. Due to this concern, we've developed
 a way to attach an existing database table as a partition zero without downtime
 and excessive database locking, what has been demonstrated in one of the
 [first proofs of concept](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80186).
@@ -150,7 +150,7 @@ Our plan is to use logical partition IDs. We want to start with the
 `ci_pipelines` table and create a `partition_id` column with a `DEFAULT` value
 of `100` or `1000`. Using a `DEFAULT` value avoids the challenge of backfilling
 this value for every row. Adding a `CHECK` constraint prior to attaching the
-first partition tells PostgreSQL that we’ve already ensured consistency and
+first partition tells PostgreSQL that we've already ensured consistency and
 there is no need to check it while holding an exclusive table lock when
 attaching this table as a partition to the routing table (partitioned schema
 definition). We will increment this value every time we create a new partition
@@ -256,12 +256,12 @@ smart enough to move rows between partitions on its own.
 
 ### Naming conventions
 
-A partitioned table is called a __routing__ table and it will use the `p_`
+A partitioned table is called a **routing** table and it will use the `p_`
 prefix which should help us with building automated tooling for query analysis.
 
-A table partition will be simply called __partition__ and it can use the a
+A table partition will be simply called **partition** and it can use the a
 physical partition ID as suffix, leaded by a `p` letter, for example
-`ci_builds_p101`. Existing CI tables will become __zero partitions__ of the
+`ci_builds_p101`. Existing CI tables will become **zero partitions** of the
 new routing tables. Depending on the chosen
 [partitioning strategy](#how-do-we-want-to-partition-cicd-data) for a given
 table, it is possible to have many logical partitions per one physical partition.
@@ -274,8 +274,8 @@ metadata table, called `ci_partitions`. In that table we would store metadata
 about all the logical partitions, with many pipelines per partition. We may
 need to store a range of pipeline ids per logical partition. Using it we will
 be able to find the `partition_id` number for a given pipeline ID and we will
-also find information about which logical partitions are “active” or
-“archived”, which will help us to implement a time-decay pattern using database
+also find information about which logical partitions are "active" or
+"archived", which will help us to implement a time-decay pattern using database
 declarative partitioning.
 
 `ci_partitions` table will store information about a partition identifier,
@@ -621,7 +621,7 @@ strategy. The strategy, described in this document, is subject to iteration as
 well. Whenever we find a better way to reduce the risk and improve our plan, we
 should update this document as well.
 
-We’ve managed to find a way to avoid large-scale data migrations, and we are
+We've managed to find a way to avoid large-scale data migrations, and we are
 building an iterative strategy for partitioning CI/CD data. We documented our
 strategy here to share knowledge and solicit feedback from other team members.
 
diff --git a/doc/ci/examples/php.md b/doc/ci/examples/php.md
index 666c4d444d8..9b9f87fffbb 100644
--- a/doc/ci/examples/php.md
+++ b/doc/ci/examples/php.md
@@ -176,7 +176,7 @@ Using phpenv also allows to easily configure the PHP environment with:
 phpenv config-add my_config.ini
 ```
 
-*__Important note:__ It seems `phpenv/phpenv`
+**Important note:** It seems `phpenv/phpenv`
  [is abandoned](https://github.com/phpenv/phpenv/issues/57). There is a fork
  at [`madumlao/phpenv`](https://github.com/madumlao/phpenv) that tries to bring
  the project back to life. [`CHH/phpenv`](https://github.com/CHH/phpenv) also
diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md
index 6547ea3895b..70a0d177ac6 100644
--- a/doc/ci/pipelines/merge_trains.md
+++ b/doc/ci/pipelines/merge_trains.md
@@ -82,8 +82,7 @@ To enable merge trains for your project:
 1. [Configure your CI/CD configuration file](merge_request_pipelines.md#prerequisites)
    so that the pipeline or individual jobs run for merge requests.
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
+1. On the left sidebar, select **Settings > Merge requests**.
 1. In the **Merge method** section, verify that **Merge commit** is selected.
 1. In the **Merge options** section, select **Enable merged results pipelines** (if not already selected) and **Enable merge trains**.
 1. Select **Save changes**.
diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md
index 777871a7c5f..172f7e26d95 100644
--- a/doc/ci/pipelines/merged_results_pipelines.md
+++ b/doc/ci/pipelines/merged_results_pipelines.md
@@ -42,9 +42,8 @@ To enable merged results pipelines in a project, you must have at least the
 Maintainer role:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Select **Enable merged results pipelines**.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge options** section, select **Enable merged results pipelines**.
 1. Select **Save changes**.
 
 WARNING:
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index b1f4331030a..e8ab13e1608 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -3882,16 +3882,13 @@ test:
 
 ### `trigger`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8997) in GitLab Premium 11.8.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/199224) to GitLab Free in 12.8.
-
 Use `trigger` to declare that a job is a "trigger job" which starts a
 [downstream pipeline](../pipelines/downstream_pipelines.md) that is either:
 
 - [A multi-project pipeline](../pipelines/downstream_pipelines.md#multi-project-pipelines).
 - [A child pipeline](../pipelines/downstream_pipelines.md#parent-child-pipelines).
 
-Trigger jobs can use only a limited set of the GitLab CI/CD configuration keywords.
+Trigger jobs can use only a limited set of GitLab CI/CD configuration keywords.
 The keywords available for use in trigger jobs are:
 
 - [`trigger`](#trigger).
@@ -3907,29 +3904,16 @@ The keywords available for use in trigger jobs are:
 
 **Possible inputs**:
 
-- For multi-project pipelines, path to the downstream project. CI/CD variables
-  [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
+- For multi-project pipelines, the path to the downstream project. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
   in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
-- For child pipelines, path to the child pipeline CI/CD configuration file.
-
-**Example of `trigger` for multi-project pipeline**:
-
-```yaml
-rspec:
-  stage: test
-  script: bundle exec rspec
+  Alternatively, use [`trigger:project](#triggerproject).
+- For child pipelines, use [`trigger:include`](#triggerinclude).
 
-staging:
-  stage: deploy
-  trigger: my/deployment
-```
-
-**Example of `trigger` for child pipelines**:
+**Example of `trigger`**:
 
 ```yaml
-trigger_job:
-  trigger:
-    include: path/to/child-pipeline.yml
+trigger-multi-project-pipeline:
+  trigger: my-group/my-project
 ```
 
 **Additional details**:
@@ -3938,8 +3922,6 @@ trigger_job:
 - In [GitLab 13.5 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201938), you
   can use [`when:manual`](#when) in the same job as `trigger`. In GitLab 13.4 and
   earlier, using them together causes the error `jobs:#{job-name} when should be on_success, on_failure or always`.
-- In [GitLab 13.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/), you can
-  view which job triggered a downstream pipeline in the [pipeline graph](../pipelines/index.md#visualize-pipelines).
 - [Manual pipeline variables](../variables/index.md#override-a-defined-cicd-variable)
   and [scheduled pipeline variables](../pipelines/schedules.md#add-a-pipeline-schedule)
   are not passed to downstream pipelines by default. Use [trigger:forward](#triggerforward)
@@ -3950,11 +3932,74 @@ trigger_job:
 **Related topics**:
 
 - [Multi-project pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-from-a-job-in-your-gitlab-ciyml-file).
-- [Child pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-parent-child-pipeline).
 - To run a pipeline for a specific branch, tag, or commit, you can use a [trigger token](../triggers/index.md)
   to authenticate with the [pipeline triggers API](../../api/pipeline_triggers.md).
   The trigger token is different than the `trigger` keyword.
 
+#### `trigger:include`
+
+Use `trigger:include` to declare that a job is a "trigger job" which starts a
+[child pipeline](../pipelines/downstream_pipelines.md#parent-child-pipelines).
+
+Use `trigger:include:artifact` to trigger a [dynamic child pipeline](../pipelines/downstream_pipelines.md#dynamic-child-pipelines).
+
+**Keyword type**: Job keyword. You can use it only as part of a job.
+
+**Possible inputs**:
+
+- The path to the child pipeline's configuration file.
+
+**Example of `trigger:include`**:
+
+```yaml
+trigger-child-pipeline:
+  trigger:
+    include: path/to/child-pipeline.gitlab-ci.yml
+```
+
+**Related topics**:
+
+- [Child pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-parent-child-pipeline).
+
+#### `trigger:project`
+
+Use `trigger:project` to declare that a job is a "trigger job" which starts a
+[multi-project pipeline](../pipelines/downstream_pipelines.md#multi-project-pipelines).
+
+By default, the multi-project pipeline triggers for the default branch. Use `trigger:branch`
+to specify a different branch.
+
+**Keyword type**: Job keyword. You can use it only as part of a job.
+
+**Possible inputs**:
+
+- The path to the downstream project. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
+  in GitLab 15.3 and later, but not [job-level persisted variables](../variables/where_variables_can_be_used.md#persisted-variables).
+
+**Example of `trigger:project`**:
+
+```yaml
+trigger-multi-project-pipeline:
+  trigger:
+    project: my-group/my-project
+```
+
+**Example of `trigger:project` for a different branch**:
+
+```yaml
+trigger-multi-project-pipeline:
+  trigger:
+    project: my-group/my-project
+    branch: development
+```
+
+**Related topics**:
+
+- [Multi-project pipeline configuration examples](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-from-a-job-in-your-gitlab-ciyml-file).
+- To run a pipeline for a specific branch, tag, or commit, you can also use a [trigger token](../triggers/index.md)
+  to authenticate with the [pipeline triggers API](../../api/pipeline_triggers.md).
+  The trigger token is different than the `trigger` keyword.
+
 #### `trigger:strategy`
 
 Use `trigger:strategy` to force the `trigger` job to wait for the downstream pipeline to complete
diff --git a/doc/development/database/not_null_constraints.md b/doc/development/database/not_null_constraints.md
index 9b3d017b09f..cd2adc3ca28 100644
--- a/doc/development/database/not_null_constraints.md
+++ b/doc/development/database/not_null_constraints.md
@@ -53,8 +53,13 @@ end
 
 ## Add a `NOT NULL` constraint to an existing column
 
-Adding `NOT NULL` to existing database columns requires multiple steps split into at least two
-different releases:
+Adding `NOT NULL` to existing database columns usually requires multiple steps split into at least two
+different releases. If your table is small enough that you don't need to
+use a background migration, you can include all these in the same merge
+request. We recommend to use separate migrations to reduce
+transaction durations.
+
+The steps required are:
 
 1. Release `N.M` (current release)
 
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 8053b4285e6..4c2f3118366 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -81,7 +81,7 @@ text = "foo\nbar"
 p text.match /^bar$/
 ```
 
-The output of this example is `#<MatchData "bar">`, as Ruby treats the input `text` line by line. In order to match the whole __string__ the Regex anchors `\A` and `\z` should be used.
+The output of this example is `#<MatchData "bar">`, as Ruby treats the input `text` line by line. To match the whole **string**, the Regex anchors `\A` and `\z` should be used.
 
 #### Impact
 
diff --git a/doc/install/migrate/compare_sm_to_saas.md b/doc/install/migrate/compare_sm_to_saas.md
new file mode 100644
index 00000000000..df79987a2fa
--- /dev/null
+++ b/doc/install/migrate/compare_sm_to_saas.md
@@ -0,0 +1,124 @@
+---
+stage: Systems
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Comparison of GitLab self-managed with GitLab SaaS
+
+GitLab SaaS is the largest hosted instance of GitLab in the world, managed by an
+[all-remote team](https://about.gitlab.com/company/culture/all-remote/) that knows GitLab best. With GitLab SaaS, updates, maintenance, and patches are all performed by this team.
+
+Self-managed GitLab gives you a deeper breadth of control over many of the functions and systems of the application.
+
+## Administration
+
+In GitLab SaaS, administration tasks are limited compared to a self-managed application.
+
+In a self-managed instance:
+
+- You have complete access and administrative control over the application, including the [Admin Area](../../user/admin_area/settings/index.md).
+- You can impersonate, create, add, and remove users.
+- You can assign the [`Auditor`](../../administration/auditor_users.md) user type and `External` role.
+
+On GitLab SaaS:
+
+- You have limited administrative control. For example, you cannot impersonate, create, add, or remove users.
+- You cannot access the [Admin Area](../../user/admin_area/settings/index.md).
+- You cannot assign the `Auditor` user type and `External` role.
+
+## Logs
+
+Logs give insight into your processes and can help GitLab Support maintain your application and resolve problems.
+
+In a self-managed instance:
+
+- You have full access to system logs.
+
+On GitLab SaaS:
+
+- You do not have access to system logs because they are at the instance level, and managed by the GitLab [infrastructure team](https://about.gitlab.com/handbook/engineering/infrastructure/).
+- You can view [Audit Events](../../administration/audit_events.md) and the [GitLab API](../../api/audit_events.md).
+- You must [request audit information](https://about.gitlab.com/handbook/support/workflows/log_requests.html) from the Support team.
+
+## Runners
+
+Runners are available for both SaaS and self-managed applications.
+
+In a self-managed instance, your runner availability and options are broader, but there are more [security concerns](https://docs.gitlab.com/runner/security/#security-for-self-managed-runners) to consider.
+
+On GitLab SaaS:
+
+- Private [runners](../../ci/runners/index.md) are available for GitLab SaaS [groups](../../user/group/index.md) and [projects](../../user/project/index.md).
+- Shared runners provided by GitLab SaaS are not configurable. Each runner instance is used once for only one job, ensuring any sensitive data left on the system is destroyed after the job is complete.
+- Shared runners are subject to usage limits and are [plan specific](https://about.gitlab.com/pricing/).
+
+## Custom Git hooks
+
+In a self-managed instance you can use any custom Git hooks.
+
+On GitLab SaaS:
+
+- SaaS users do not have access to the file system, and cannot use custom Git hooks.
+- You can use [webhooks](../../user/project/integrations/webhooks.md) as an alternative.
+
+## API and GraphQL
+
+In a self-managed instance, users can access all API endpoints, including those that require instance `admin` permissions.
+
+On GitLab SaaS:
+
+- SaaS users have access to all of the [API endpoints](../../api/index.md) except those that require instance `admin` permissions.
+- Only authorized GitLab engineers have administrative access.
+
+## Authentication
+
+In a self-managed instance:
+
+- You can use an internal encryption key for your data store.
+- You can view console logs.
+- You can enforce jobs on every pipeline across the group or organization.
+- You have control over your data backup.
+- You can use the [Interactive Web Terminal](../../ci/interactive_web_terminal/index.md#interactive-web-terminals) for shared runners.
+
+On GitLab SaaS:
+
+- You cannot use internal encryption key for the data store ([bring-your-own-key](https://about.gitlab.com/handbook/engineering/security/vulnerability_management/encryption-policy.html#rolling-your-own-crypto)).
+- You cannot view console logs.
+- You cannot enforce jobs on every pipeline across the group or organization.
+- You cannot configure or control data backups. You must use [group](../../api/group_import_export.md) and [project](../../api/project_import_export.md) export.
+- The [Interactive Web Terminal](../../ci/interactive_web_terminal/index.md#interactive-web-terminals) is not available for shared runners.
+
+## Public or private projects
+
+Project privacy is different when using a self-managed application or GitLab SaaS.
+
+In a self-managed instance, you control who can view your projects.
+
+On GitLab SaaS:
+
+- The GitLab SaaS instance is open to the public.
+- When your projects are set as `Public`, they are open to everyone on the public internet.
+
+## Encryption
+
+In a self-managed instance, you control the encryption type and configuration.
+
+On GitLab SaaS:
+
+- An [Access Management Process](https://about.gitlab.com/handbook/engineering/security/#access-management-process) is in place.
+- All data on GitLab.com is encrypted at rest by default. Access to encryption keys is strictly managed by GitLab.
+- GitLab does not access your tenant data except as part of a verified service request from you.
+
+## Support
+
+In a self-managed instance:
+
+- You can access any of your back-end systems.
+- Our Support team can request logs to assist you.
+
+On GitLab SaaS:
+
+- For your privacy and security, there is no public access to GitLab back-end systems.
+- Support staff work with [Site Reliability Engineers](https://about.gitlab.com/job-families/engineering/infrastructure/site-reliability-engineer/) to support the [infrastructure](https://about.gitlab.com/handbook/engineering/infrastructure/).
+- GitLab Support can access instance logs and view projects, as well as impersonate users. The Support Team can access your logs.
diff --git a/doc/integration/jira/issues.md b/doc/integration/jira/issues.md
index 2d9e928e654..a0b102eb21f 100644
--- a/doc/integration/jira/issues.md
+++ b/doc/integration/jira/issues.md
@@ -55,9 +55,8 @@ You can prevent merge requests from being merged if they do not refer to a Jira
 To enforce this:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Under **Merge checks**, select the **Require an associated issue from Jira** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge checks** section, select **Require an associated issue from Jira**.
 1. Select **Save**.
 
 After you enable this feature, a merge request that doesn't reference an associated
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index 7540ae8450f..d82a6ab5e8e 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -340,9 +340,8 @@ resolved. When this setting is enabled, the **Unresolved threads** counter in a
 is shown in orange when at least one thread remains unresolved.
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Under **Merge checks**, select the **All threads must be resolved** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge checks** section, select the **All threads must be resolved** checkbox.
 1. Select **Save changes**.
 
 ### Automatically resolve threads in a merge request when they become outdated
@@ -351,10 +350,9 @@ You can set merge requests to automatically resolve threads when lines are modif
 with a new push.
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Under **Merge options**, select the
-   **Automatically resolve merge request diff threads when they become outdated** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge options** section, select
+   **Automatically resolve merge request diff threads when they become outdated**.
 1. Select **Save changes**.
 
 Threads are now resolved if a push makes a diff section outdated.
diff --git a/doc/user/markdown.md b/doc/user/markdown.md
index 98f19750d49..6f90a9f0b1f 100644
--- a/doc/user/markdown.md
+++ b/doc/user/markdown.md
@@ -774,6 +774,8 @@ Combined emphasis with **asterisks and _underscores_**.
 Strikethrough uses two tildes. ~~Scratch this.~~
 ```
 
+<!-- markdownlint-disable MD050 -->
+
 Emphasis, aka italics, with *asterisks* or _underscores_.
 
 Strong emphasis, aka bold, with double **asterisks** or __underscores__.
@@ -782,6 +784,8 @@ Combined emphasis with **asterisks and _underscores_**.
 
 Strikethrough uses two tildes. ~~Scratch this.~~
 
+<!-- markdownlint-enable MD050 -->
+
 #### Multiple underscores in words and mid-word emphasis
 
 If this section isn't rendered correctly,
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index 5df3a973cca..2a060430a7c 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -135,9 +135,8 @@ To set a default description template for merge requests, either:
 - Users on GitLab Premium and higher: set the default template in project settings:
 
   1. On the top bar, select **Menu > Projects** and find your project.
-  1. On the left sidebar, select **Settings**.
-  1. Expand **Merge requests**.
-  1. Fill in the **Default description template for merge requests** text area.
+  1. On the left sidebar, select **Settings > Merge requests**.
+  1. In the **Merge commit message template** section, fill in **Default description template for merge requests**.
   1. Select **Save changes**.
 
 To set a default description template for issues, either:
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index c9278c19322..32548215054 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -32,8 +32,9 @@ use the default approval rules from the target (upstream) project, not the sourc
 
 To add a merge request approval rule:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**, and then select **Add approval rule**.
+1. Go to your project and select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval rules**.
+1. Select **Add approval rule**.
 1. Add a human-readable **Rule name**.
 1. Set the number of required approvals in **Approvals required**. A value of `0` makes
    [the rule optional](#configure-optional-approval-rules), and any number greater than `0`
@@ -65,8 +66,9 @@ to existing merge requests:
 
 To edit a merge request approval rule:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**, and then select **Edit**.
+1. Go to your project and select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval rules**.
+1. Select **Edit** next to the rule you want to edit.
 1. Optional. Change the **Rule name**.
 1. Set the number of required approvals in **Approvals required**. The minimum value is `0`.
 1. Add or remove eligible approvers, as needed:
@@ -155,11 +157,11 @@ approve in these ways:
 If you add [code owners](../../code_owners.md) to your repository, the owners of files
 become eligible approvers in the project. To enable this merge request approval rule:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Locate **All eligible users** and select the number of approvals required:
+1. Go to your project and select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval rules**.
+1. Locate the **All eligible users** rule, and select the number of approvals required:
 
-![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v15_2.png)
+   ![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v15_2.png)
 
 You can also
 [require code owner approval](../../protected_branches.md#require-code-owner-approval-on-a-protected-branch)
@@ -182,9 +184,10 @@ granting them push access:
    and select the Reporter role for the user.
 1. [Share the project with your group](../../members/share_project_with_groups.md#share-a-project-with-a-group-of-users),
    based on the Reporter role.
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Select **Add approval rule** or **Update approval rule** and target the protected branch.
+1. Go to your project and select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval rules**, and either:
+   - For a new rule, select **Add approval rule** and target the protected branch.
+   - For an existing rule, select **Edit** and target the protected branch.
 1. [Add the group](../../../group/manage.md#create-a-group) to the permission list.
 
    ![Update approval rule](img/update_approval_rule_v13_10.png)
@@ -226,12 +229,12 @@ Approval rules are often relevant only to specific branches, like your
 approval rule for certain branches:
 
 1. [Create an approval rule](#add-an-approval-rule).
-1. Go to your project and select **Settings**.
-1. Expand **Merge request (MR) approvals**.
+1. Go to your project and select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval rules**.
 1. Select a **Target branch**:
    - To apply the rule to all branches, select **All branches**.
    - To apply the rule to all protected branches, select **All protected branches** (GitLab 15.3 and later).
-   - To apply the rule to a specific branch, select it from the list:
+   - To apply the rule to a specific branch, select it from the list.
 
 1. To enable this configuration, read
    [Code Owner's approvals for protected branches](../../protected_branches.md#require-code-owner-approval-on-a-protected-branch).
diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md
index 3ca8ddb508a..4fdf6d46b8b 100644
--- a/doc/user/project/merge_requests/approvals/settings.md
+++ b/doc/user/project/merge_requests/approvals/settings.md
@@ -16,8 +16,8 @@ those rules are applied as a merge request moves toward completion.
 
 To view or edit merge request approval settings:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
+1. Go to your project and select **Settings > Merge requests**.
+1. Expand **Approvals**.
 
 ### Approval settings
 
@@ -44,9 +44,9 @@ You can further define what happens to existing approvals when commits are added
 
 By default, the author of a merge request cannot approve it. To change this setting:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Clear the **Prevent approval by author** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   clear the **Prevent approval by author** checkbox.
 1. Select **Save changes**.
 
 Authors can edit the approval rule in an individual merge request and override
@@ -68,9 +68,9 @@ the project level or [instance level](../../../admin_area/merge_requests_approva
 you can prevent committers from approving merge requests that are partially
 their own. To do this:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Select the **Prevent approvals by users who add commits** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   select **Prevent approvals by users who add commits**.
    If this checkbox is cleared, an administrator has disabled it
    [at the instance level](../../../admin_area/merge_requests_approvals.md), and
    it can't be changed at the project level.
@@ -94,9 +94,9 @@ By default, users can override the approval rules you [create for a project](rul
 on a per-merge-request basis. If you don't want users to change approval rules
 on merge requests, you can disable this setting:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Select the **Prevent editing approval rules in merge requests** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   select **Prevent editing approval rules in merge requests**.
 1. Select **Save changes**.
 
 This change affects all open merge requests.
@@ -112,9 +112,9 @@ permission enables an electronic signature for approvals, such as the one define
 
 1. Enable password authentication for the web interface, as described in the
    [sign-in restrictions documentation](../../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Select the **Require user password to approve** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   select **Require user password to approve**.
 1. Select **Save changes**.
 
 ## Remove all approvals when commits are added to the source branch
@@ -123,9 +123,9 @@ By default, an approval on a merge request remains in place, even if you add mor
 after the approval. If you want to remove all existing approvals on a merge request
 when more changes are added to it:
 
-1. Go to your project and select **Settings > General**.
-1. Expand **Merge request (MR) approvals**.
-1. Select the **Remove all approvals when commits are added to the source branch** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   select **Remove all approvals when commits are added to the source branch**.
 1. Select **Save changes**.
 
 Approvals aren't removed when a merge request is [rebased from the UI](../methods/index.md#rebasing-in-semi-linear-merge-methods)
@@ -143,10 +143,9 @@ Prerequisite:
 
 To do this:
 
-1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge request approvals**.
-1. Select **Remove approvals by Code Owners if their files changed**.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge request approvals** section, scroll to **Approval settings** and
+   select **Remove approvals by Code Owners if their files changed**.
 1. Select **Save changes**.
 
 ## Code coverage check approvals
diff --git a/doc/user/project/merge_requests/commit_templates.md b/doc/user/project/merge_requests/commit_templates.md
index 6f9bc452b96..6b27ea4471c 100644
--- a/doc/user/project/merge_requests/commit_templates.md
+++ b/doc/user/project/merge_requests/commit_templates.md
@@ -30,7 +30,7 @@ Prerequisite:
 To do this:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General** and expand **Merge requests**.
+1. On the left sidebar, select **Settings > Merge requests**.
 1. Depending on the type of template you want to create, scroll to either
    [**Merge commit message template**](#default-template-for-merge-commits) or
    [**Squash commit message template**](#default-template-for-squash-commits).
diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
index 9182cf11566..c1b85bb4acc 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -57,9 +57,8 @@ does not disable this feature, as it is possible to use pipelines from external
 CI providers with this feature. To enable it, you must:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Under **Merge checks**, select the **Pipelines must succeed** checkbox.
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge checks** section, select **Pipelines must succeed**.
 1. Select **Save**.
 
 This setting also prevents merge requests from being merged if there is no pipeline.
@@ -106,11 +105,10 @@ When the **Pipelines must succeed** checkbox is checked, [skipped pipelines](../
 merge requests from being merged. To change this behavior:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
-1. Under **Merge checks**:
+1. On the left sidebar, select **Settings > Merge requests**.
+1. In the **Merge checks** section:
    - Ensure **Pipelines must succeed** is selected.
-   - Select the **Skipped pipelines are considered successful** checkbox.
+   - Select **Skipped pipelines are considered successful**.
 1. Select **Save**.
 
 ## From the command line
diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md
index 7860221a950..02a784a321c 100644
--- a/doc/user/project/merge_requests/methods/index.md
+++ b/doc/user/project/merge_requests/methods/index.md
@@ -13,8 +13,7 @@ merge requests are merged into an existing branch.
 ## Configure a project's merge method
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
+1. On the left sidebar, select **Settings > Merge requests**.
 1. In the **Merge method** section, select your desired merge method.
 1. Select **Save changes**.
 
diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md
index 7e37990b9bf..e113dcfdb58 100644
--- a/doc/user/project/merge_requests/squash_and_merge.md
+++ b/doc/user/project/merge_requests/squash_and_merge.md
@@ -61,8 +61,7 @@ squash the commits as part of the merge process:
 To configure the default squashing behavior for all merge requests in your project:
 
 1. On the top bar, select **Menu > Projects** and find your project.
-1. On the left sidebar, select **Settings > General**.
-1. Expand **Merge requests**.
+1. On the left sidebar, select **Settings > Merge requests**.
 1. In the **Squash commits when merging** section, select your desired behavior:
    - **Do not allow**: Squashing is never performed, and the option is not displayed.
    - **Allow**: Squashing is allowed, but cleared by default.
diff --git a/doc/user/project/merge_requests/status_checks.md b/doc/user/project/merge_requests/status_checks.md
index 0d7794a3ebd..f6c55210419 100644
--- a/doc/user/project/merge_requests/status_checks.md
+++ b/doc/user/project/merge_requests/status_checks.md
@@ -61,9 +61,8 @@ using the API. You don't need to wait for a merge request webhook payload to be
 
 Within each project's settings, you can see a list of status checks added to the project:
 
-1. In your project, go to **Settings > General**.
-1. Expand the **Merge requests** section.
-1. Scroll down to the **Status checks** sub-section.
+1. In your project, go to **Settings > Merge requests** section.
+1. Scroll down to **Status checks**.
 
 ![Status checks list](img/status_checks_list_view_v14_0.png)