Add latest changes from gitlab-org/gitlab@master

16 files changed, 286 insertions, 143 deletions

diff --git a/doc/administration/dedicated/index.md b/doc/administration/dedicated/index.md
index bfb7c76fd7f..ef9e53c8fb7 100644
--- a/doc/administration/dedicated/index.md
+++ b/doc/administration/dedicated/index.md
@@ -216,8 +216,9 @@ Make sure the AWS KMS keys are replicated to your desired primary, secondary and
 
 ### Configuration change policy
 
-Configuration changes are batched up and applied during your environment's weekly four-hour maintenance
-window.
+Configuration changes requested with a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) are batched up and applied during your environment's weekly four-hour maintenance window.
+
+This policy does not apply to configuration changes made by a GitLab Dedicated tenant admin [using Switchboard](#configuration-changes-in-switchboard).
 
 To have a change considered for an upcoming weekly maintenance window, all required information
 must be submitted in full two business days before the start of the window.
@@ -226,14 +227,20 @@ A configuration change might not be applied during an upcoming weekly maintenanc
 it meets the minimum lead time. If GitLab needs to perform high-priority maintenance tasks that
 run beyond the maintenance window, configuration changes will be postponed to the following week.
 
-Changes cannot be applied outside of a weekly maintenance window unless it qualifies for
+Changes requested with a support ticket cannot be applied outside of a weekly maintenance window unless it qualifies for
 [emergency support](https://about.gitlab.com/support/#how-to-engage-emergency-support).
 
-### Making configuration changes
+### Configuration changes in Switchboard
 
 Switchboard empowers the user to make limited configuration changes to their Dedicated Tenant Instance. As Switchboard matures further configuration changes will be made available.
 
-To change or update the configuration of your GitLab Dedicated instance, use Switchboard following the instructions in the relevant section or open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) with your request. You can request configuration changes for the options originally specified during onboarding, or for any of the following optional features.
+To change or update the configuration of your GitLab Dedicated instance, use Switchboard following the instructions in the relevant section or open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) with your request.
+
+You can request configuration changes for some of the options originally specified during onboarding, or for any of the following optional features.
+
+Configuration changes made with Switchboard can be applied immediately or deferred until your next scheduled weekly [maintenance window](#maintenance-window).
+
+When applied immediately, changes may take up to 90 minutes to be deployed to your environment. Individual changes are applied in the order they are saved, or you may choose to save several changes at once before applying them in one batch.
 
 ### Inbound Private Link
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 7d3c4099440..fbba2f2474b 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -15388,7 +15388,6 @@ Represents the total number of issues and their weights for a particular day.
 | <a id="cicatalogresourceopenissuescount"></a>`openIssuesCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.3. This feature is an Experiment. It can be changed or removed at any time. Count of open issues that belong to the the catalog resource. |
 | <a id="cicatalogresourceopenmergerequestscount"></a>`openMergeRequestsCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.3. This feature is an Experiment. It can be changed or removed at any time. Count of open merge requests that belong to the the catalog resource. |
 | <a id="cicatalogresourcereadmehtml"></a>`readmeHtml` **{warning-solid}** | [`String!`](#string) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. GitLab Flavored Markdown rendering of `readme`. |
-| <a id="cicatalogresourcerootnamespace"></a>`rootNamespace` **{warning-solid}** | [`Namespace`](#namespace) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Root namespace of the catalog resource. |
 | <a id="cicatalogresourcestarcount"></a>`starCount` **{warning-solid}** | [`Int!`](#int) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Number of times the catalog resource has been starred. |
 | <a id="cicatalogresourcewebpath"></a>`webPath` **{warning-solid}** | [`String`](#string) | **Introduced** in 16.1. This feature is an Experiment. It can be changed or removed at any time. Web path of the catalog resource. |
 
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index e67f636b14f..f20f2fd5e3f 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -11,33 +11,36 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Feature flag `ci_namespace_catalog_experimental` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/394772) in GitLab 16.3.
 > - [Moved](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/130824) to [Beta status](../../policy/experiment-beta-support.md) in GitLab 16.6.
 
-A CI/CD component is a reusable single pipeline configuration unit. Use them to compose an entire pipeline configuration or a small part of a larger pipeline.
+A CI/CD component is a reusable single pipeline configuration unit. Use components
+to create a small part of a larger pipeline, or even to compose a complete pipeline configuration.
 
-A component can take [input parameters](../yaml/inputs.md).
+A component can be configured with [input parameters](../yaml/inputs.md) for more
+dynamic behavior.
 
-CI/CD components are similar to the other kinds of [configuration added with the `include` keyword](../yaml/includes.md), but have several advantages:
+CI/CD components are similar to the other kinds of [configuration added with the `include` keyword](../yaml/includes.md),
+but have several advantages:
 
+- Components can be listed in the [CI/CD Catalog](#cicd-catalog).
 - Components can be released and used with a specific version.
 - Multiple components can be defined in the same project and versioned together.
-- Components are discoverable in the [CI/CD Catalog](#cicd-catalog).
+
+Instead of creating your own components, you can also search for published components
+that have the functionality you need in the [CI/CD Catalog](#cicd-catalog).
 
 ## Component project
 
 A component project is a GitLab project with a repository that hosts one or more components.
-All components in the project are versioned together.
+All components in the project are versioned together, with a maximum of 10 components per project.
 
 If a component requires different versioning from other components, the component should be moved
 to a dedicated component project.
 
-One component repository can have a maximum of 10 components.
-
 ### Create a component project
 
 To create a component project, you must:
 
 1. [Create a new project](../../user/project/index.md#create-a-blank-project) with a `README.md` file.
 1. Add a YAML configuration file for each component, following the [required directory structure](#directory-structure).
-
    For example:
 
    ```yaml
@@ -51,6 +54,9 @@ To create a component project, you must:
      stage: $[[ inputs.stage ]]
    ```
 
+You can [use the component](#use-a-component) immediately, but you might want to consider
+publishing the component to the [CI/CD catalog](#cicd-catalog).
+
 ### Directory structure
 
 The repository must contain:
@@ -65,39 +71,40 @@ The repository must contain:
 Configure the project's `.gitlab-ci.yml` to [test the components](#test-the-component)
 and [release new versions](#publish-a-new-release).
 
-For example, if the project contains a single component, the directory structure should be similar to:
+For example:
 
-```plaintext
-├── templates/
-│   └── secret-detection.yml
-├── README.md
-└── .gitlab-ci.yml
-```
+- If the project contains a single component, the directory structure should be similar to:
 
-If the project contains multiple components, then the directory structure should be similar to:
+  ```plaintext
+  ├── templates/
+  │   └── my-component.yml
+  ├── README.md
+  └── .gitlab-ci.yml
+  ```
 
-```plaintext
-├── templates/
-│   ├── all-scans.yml
-│   └── secret-detection/
-│       ├── template.yml
-│       ├── Dockerfile
-│       └── test.sh
-├── README.md
-└── .gitlab-ci.yml
-```
+- If the project contains multiple components, then the directory structure should be similar to:
+
+  ```plaintext
+  ├── templates/
+  │   ├── my-simple-component.yml
+  │   └── my-complex-component/
+  │       ├── template.yml
+  │       ├── Dockerfile
+  │       └── test.sh
+  ├── README.md
+  └── .gitlab-ci.yml
+  ```
 
-In this example:
+  In this example:
 
-- The `all-scans` component configuration is defined in a single file.
-- The `secret-detection` component configuration contains multiple files in a directory.
+  - The `my-simple-component` component's configuration is defined in a single file.
+  - The `my-complex-component` component's configuration contains multiple files in a directory.
 
 ## Use a component
 
-You can use a component in a CI/CD configuration with the `include: component` keyword.
-The component is identified by a unique address formatted as `<fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>`.
-
-For example:
+To add a component to a project's CI/CD configuration, use the [`include: component`](../yaml/index.md#includecomponent)
+keyword. The component reference is formatted as `<fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>`,
+for example:
 
 ```yaml
 include:
@@ -113,15 +120,22 @@ In this example:
 - `my-org/security-components` is the full path of the project containing the component.
 - `secret-detection` is the component name that is defined as either a single file `templates/secret-detection.yml`
   or as a directory `templates/secret-detection/` containing a `template.yml`.
-- `1.0` is the version of the component. In order of highest priority first,
-  the version can be:
-  - A branch name, for example `main`.
-  - A commit SHA, for example `e3262fdd0914fa823210cdb79a8c421e2cef79d8`.
-  - A tag, for example: `1.0`. If a tag and branch exist with the same name, the tag
-    takes precedence over the branch. If a tag and commit SHA exist with the same name,
-    the commit SHA takes precedence over the tag.
-  - `~latest`, which is a special version that always points to the most recent
-    [release published in the CI/CD Catalog](#publish-a-new-release).
+- `1.0` is the [version](#component-versions) of the component.
+
+When GitLab creates a new pipeline, the component's configuration is fetched and added to
+the pipeline's configuration.
+
+### Component versions
+
+In order of highest priority first, the component version can be:
+
+- A commit SHA, for example `e3262fdd0914fa823210cdb79a8c421e2cef79d8`.
+- A tag, for example: `1.0`. If a tag and commit SHA exist with the same name,
+  the commit SHA takes precedence over the tag.
+- A branch name, for example `main`. If a branch and tag exist with the same name,
+  the tag takes precedence over the branch.
+- `~latest`, which is a special version that always points to the most recent
+  [release published in the CI/CD Catalog](#publish-a-new-release).
 
 NOTE:
 The `~latest` version keyword always returns the most recent published release, not the release with
@@ -135,10 +149,11 @@ change this behavior.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407249) in GitLab 16.1 as an [experiment](../../policy/experiment-beta-support.md#experiment).
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/432045) to [beta](../../policy/experiment-beta-support.md#beta) in GitLab 16.7.
 
-The CI/CD Catalog is a list of projects with published CI/CD components you can use to extend your CI/CD workflow.
+The CI/CD Catalog is a list of projects with published CI/CD components you can use
+to extend your CI/CD workflow.
 
-Anyone can add a [component project](index.md#component-project) to the CI/CD Catalog, or contribute
-to an existing project to improve the available components.
+Anyone can [create a component project](#create-a-component-project) and add it to
+the CI/CD Catalog, or contribute to an existing project to improve the available components.
 
 ### View the CI/CD Catalog
 
@@ -164,62 +179,64 @@ To publish a component project in the CI/CD catalog, you must:
 #### Set a component project as a catalog resource
 
 To make published versions of a component project visible in the CI/CD catalog,
-you must set the project as a catalog resource:
+you must set the project as a catalog resource.
+
+Prerequisites:
+
+- You must have the Owner role in the project.
+
+To set the project as a catalog resource:
 
 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Settings > General**.
 1. Expand **Visibility, project features, permissions**.
-1. Scroll down to **CI/CD Catalog resource** and select the toggle to mark the project as a catalog resource.
+1. Turn on the **CI/CD Catalog resource** toggle.
 
-#### Publish a new release
+The project only becomes findable in the catalog after you publish a new release.
 
-Components defined in a [component project](#component-project) can be [used](#use-a-component)
-immediately and don't require to be published in the CI/CD catalog. However, having the component
-project published in the catalog makes it discoverable to other users.
+#### Publish a new release
 
-After the project is set as a [catalog resource](#set-a-component-project-as-a-catalog-resource),
-add a job to the project's `.gitlab-ci.yml` file that creates a release using the
-[`release`](../yaml/index.md#release) keyword.
+CI/CD components can be [used](#use-a-component) without being listed in the CI/CD catalog.
+However, publishing a component's releases in the catalog makes it discoverable to other users.
 
-For example:
-
-```yaml
-create-release:
-  stage: deploy
-  image: registry.gitlab.com/gitlab-org/release-cli:latest
-  script: echo "Creating release $CI_COMMIT_TAG"
-  release:
-    tag_name: $CI_COMMIT_TAG
-    description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"
-```
+Prerequisites:
 
-The release fails if the project is missing:
+- The project must:
+  - Be set as a [catalog resource](#set-a-component-project-as-a-catalog-resource).
+  - Have a [project description](../../user/project/working_with_projects.md#edit-project-name-and-description) defined.
+  - Have a `README.md` file in the root directory for the commit SHA of the tag being released.
+  - Have at least one [CI/CD component in the `templates/` directory](#directory-structure)
+    for the commit SHA of the tag being released.
 
-- The [project description](../../user/project/working_with_projects.md#edit-project-name-and-description),
-  to display in the catalog list.
-- A `README.md` file in the root directory for the commit SHA of the tag being released.
-- Any component in the `templates/` directory for the commit SHA of the tag being released.
+To publish a new version of the component to the catalog:
 
-Create a [new tag](../../user/project/repository/tags/index.md#create-a-tag) for the release,
-which should trigger a tag pipeline that contains the job responsible that creates the release.
-You should configure the tag pipeline to [test the components](#test-the-component) before
-running the release job.
+1. Add a job to the project's `.gitlab-ci.yml` file that uses the [`release`](../yaml/index.md#release)
+   keyword to create the new release. For example:
 
-The release is created and the new version is published to the CI/CD catalog only if:
+   ```yaml
+   create-release:
+     stage: deploy
+     image: registry.gitlab.com/gitlab-org/release-cli:latest
+     script: echo "Creating release $CI_COMMIT_TAG"
+     rules:
+       - if: $CI_COMMIT_TAG
+     release:
+       tag_name: $CI_COMMIT_TAG
+       description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"
+   ```
 
-- All jobs before the release job succeed.
-- All component project [requirements](#directory-structure) are satisfied.
-- The component project is [set as a catalog resource](#set-a-component-project-as-a-catalog-resource).
+1. Create a [new tag](../../user/project/repository/tags/index.md#create-a-tag) for the release,
+   which should trigger a tag pipeline that contains the job responsible for creating the release.
+   You should configure the tag pipeline to [test the components](#test-the-component) before
+   running the release job.
 
-NOTE:
-If you disable [catalog resource setting](#set-a-component-project-as-a-catalog-resource),
-the component project and all versions are removed from the catalog. To publish it again,
-you must re-enable the setting and release a new version.
+After the release job completes successfully, the release is created and the new version
+is published to the CI/CD catalog.
 
 ### Unpublish a component project
 
-To remove a component project from the catalog, turn off the [**CI/CD Catalog resource**](#set-a-component-project-as-a-catalog-resource) toggle.
-in the project settings.
+To remove a component project from the catalog, turn off the [**CI/CD Catalog resource**](#set-a-component-project-as-a-catalog-resource)
+toggle in the project settings.
 
 WARNING:
 This action destroys the metadata about the component project and its versions published
@@ -251,9 +268,9 @@ include:
 
 stages: [build, test, release]
 
-# Expect `component-job` is added.
-# This example tests that the included component works as expected.
-# You can inspect data generated by the component, use GitLab API endpoints or third-party tools.
+# Check if `component-job` is added.
+# This example job could also test that the included component works as expected.
+# You can inspect data generated by the component, use GitLab API endpoints, or third-party tools.
 ensure-job-added:
   stage: test
   image: badouralix/curl-jq
@@ -265,8 +282,8 @@ ensure-job-added:
         exit 1
       fi
 
-# If we are tagging a release with a semantic version and all previous checks succeeded,
-# we proceed with creating a release automatically.
+# If the pipeline is for a new tag with a semantic version, and all previous jobs succeed,
+# create the release.
 create-release:
   stage: release
   image: registry.gitlab.com/gitlab-org/release-cli:latest
@@ -278,7 +295,8 @@ create-release:
     description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"
 ```
 
-After committing and pushing changes, the pipeline tests the component, then releases the tag it if the test passes.
+After committing and pushing changes, the pipeline tests the component, then creates
+a release if the earlier jobs pass.
 
 ### Avoid using global keywords
 
@@ -286,7 +304,7 @@ Avoid using [global keywords](../yaml/index.md#global-keywords) in a component.
 Using these keywords in a component affects all jobs in a pipeline, including jobs
 directly defined in the main `.gitlab-ci.yml` or in other included components.
 
-As an alternative to global keywords, instead:
+As an alternative to global keywords:
 
 - Add the configuration directly to each job, even if it creates some duplication
   in the component configuration.
@@ -294,7 +312,7 @@ As an alternative to global keywords, instead:
   unique names that reduce the risk of naming conflicts when the component is merged
   into the configuration.
 
-For example, using the `default` keyword is not recommended:
+For example, avoid using the `default` global keyword:
 
 ```yaml
 # Not recommended
@@ -310,7 +328,7 @@ rspec-2:
 
 Instead, you can:
 
-- Add the configuration to each job:
+- Add the configuration to each job explicitly:
 
   ```yaml
   rspec-1:
@@ -339,21 +357,21 @@ Instead, you can:
     script: bundle exec rspec dir2/
   ```
 
-### Replace hard-coded values with inputs
+### Replace hardcoded values with inputs
 
-Avoid hard-coding values in CI/CD components. Hard-coded values might force
+Avoid using hardcoded values in CI/CD components. Hardcoded values might force
 component users to need to review the component's internal details and adapt their pipeline
 to work with the component.
 
 A common keyword with problematic hard-coded values is `stage`. If a component job's
-stage is set to a specific value, the pipeline using the component **must** define
-the exact same stage. Additionally, if the component user wants to use a different stage,
-they must [override](../yaml/includes.md#override-included-configuration-values) the configuration.
+stage is hardcoded, all pipelines using the component **must** either define
+the exact same stage, or [override](../yaml/includes.md#override-included-configuration-values)
+the configuration.
 
-The preferred method is to use the [`input` keyword](../yaml/inputs.md).
-The component user can specify the exact value they need.
+The preferred method is to use the [`input` keyword](../yaml/inputs.md) for dynamic
+component configuration. The component user can specify the exact value they need.
 
-For example:
+For example, to create a component with `stage` configuration that can be defined by users:
 
 - In the component configuration:
 
@@ -372,28 +390,28 @@ For example:
     script: echo integration tests
   ```
 
-- In the project using the component:
+- In a project using the component:
 
   ```yaml
+  stages: [verify, deploy]
+
   include:
     - component: gitlab.com/gitlab-org/ruby-test@1.0
       inputs:
         stage: verify
-
-  stages: [verify, deploy]
   ```
 
 ### Replace custom CI/CD variables with inputs
 
 When using CI/CD variables in a component, evaluate if the `inputs` keyword
-should be used instead. Avoid requiring a user to define custom variables to change a component's
-behavior. You should try to use `inputs` for any component customization.
+should be used instead. Avoid asking users to define custom variables to configure
+components when `inputs` is a better solution.
 
-Inputs are explicitly defined in the component's specs, and are better validated than variables.
+Inputs are explicitly defined in the component's specs, and have better validation than variables.
 For example, if a required input is not passed to the component, GitLab returns a pipeline error.
 By contrast, if a variable is not defined, its value is empty, and there is no error.
 
-For example, use `inputs` instead of variables to let users change a scanner's output format:
+For example, use `inputs` instead of variables to configure a scanner's output format:
 
 - In the component configuration:
 
@@ -416,18 +434,17 @@ For example, use `inputs` instead of variables to let users change a scanner's o
         scanner-output: yaml
   ```
 
-In other cases, CI/CD variables are still preferred, including:
+In other cases, CI/CD variables might still be preferred. For example:
 
-- Using [predefined variables](../variables/predefined_variables.md) to automatically configure
+- Use [predefined variables](../variables/predefined_variables.md) to automatically configure
   a component to match a user's project.
-- Requiring tokens or other sensitive values to be stored as [masked or protected variables in project settings](../variables/index.md#define-a-cicd-variable-in-the-ui).
+- Ask users to store sensitive values as [masked or protected CI/CD variables in project settings](../variables/index.md#define-a-cicd-variable-in-the-ui).
 
 ### Use semantic versioning
 
-When tagging and [releasing new versions](#publish-a-new-release) of components, you should use
-[semantic versioning](https://semver.org).
-Semantic versioning is the standard for communicating that a change is a major, minor, patch,
-or other kind of change.
+When tagging and [releasing new versions](#publish-a-new-release) of components,
+you should use [semantic versioning](https://semver.org). Semantic versioning is the standard
+for communicating that a change is a major, minor, patch, or other kind of change.
 
 You should use at least the `major.minor` format, as this is widely understood. For example,
 `2.0` or `2.1`.
@@ -444,9 +461,9 @@ Other examples of semantic versioning:
 Any existing CI/CD template that you use in projects by using the `include:` syntax
 can be converted to a CI/CD component:
 
-1. Decide if you want the component to be part of an existing [component project](index.md#component-project)
-   to be grouped with other components, or [create a new component project](#create-a-component-project).
-1. Create a YAML file in the component project according to the expected [directory structure](index.md#directory-structure).
+1. Decide if you want the component to be grouped with other components as part of
+   an existing [component project](index.md#component-project), or [create a new component project](#create-a-component-project).
+1. Create a YAML file in the component project according to the [directory structure](index.md#directory-structure).
 1. Copy the content of the original template YAML file into the new component YAML file.
 1. Refactor the new component's configuration to:
    - Follow the [best practices](index.md#best-practices) for components.
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 0b7911ef436..df2330e04f6 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -190,6 +190,27 @@ The time limit to resolve all files is 30 seconds.
 - [Use variables with `include`](includes.md#use-variables-with-include).
 - [Use `rules` with `include`](includes.md#use-rules-with-include).
 
+#### `include:component`
+
+Use `include:component` to add a [CI/CD component](../components/index.md) to the
+pipeline configuration.
+
+**Keyword type**: Global keyword.
+
+**Possible inputs**: The full address of the CI/CD component, formatted as
+`<fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>`.
+
+**Example of `include:component`**:
+
+```yaml
+include:
+  - component: gitlab.example.com/my-org/security-components/secret-detection@1.0
+```
+
+**Related topics**:
+
+- [Use a CI/CD component](../components/index.md#use-a-component).
+
 #### `include:local`
 
 Use `include:local` to include a file that is in the same repository and branch as the configuration file containing the `include` keyword.
diff --git a/doc/development/backend/create_source_code_be/index.md b/doc/development/backend/create_source_code_be/index.md
index 6f444369129..3ae3c989966 100644
--- a/doc/development/backend/create_source_code_be/index.md
+++ b/doc/development/backend/create_source_code_be/index.md
@@ -29,6 +29,10 @@ Source Code Management shares ownership of Code Owners with the Code Review grou
 
 - [Approval Rules](../../merge_request_concepts/approval_rules.md)
 
+### Push Rules
+
+- [Push Rules development guidelines](../../push_rules/index.md)
+
 ### Protected Branches
 
 Details about Protected Branches models can be found in the [Code Owners](../../code_owners/index.md#related-models) technical reference page.
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index dcbb15e5811..c25c4751ee8 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -193,7 +193,7 @@ where Danger is already configured.
 
 Contributors can configure Danger for their forks with the following steps:
 
-1. Create a [personal API token](https://gitlab.com/-/profile/personal_access_tokens?name=GitLab+Dangerbot&scopes=api)
+1. Create a [personal API token](https://gitlab.com/-/user_settings/personal_access_tokens?name=GitLab+Dangerbot&scopes=api)
   that has the `api` scope set (don't forget to copy it to the clipboard).
 1. In your fork, add a [project CI/CD variable](../ci/variables/index.md#for-a-project)
   called `DANGER_GITLAB_API_TOKEN` with the token copied in the previous step.
diff --git a/doc/development/integrations/jira_connect.md b/doc/development/integrations/jira_connect.md
index 338c93db78a..fd5ff66243a 100644
--- a/doc/development/integrations/jira_connect.md
+++ b/doc/development/integrations/jira_connect.md
@@ -73,7 +73,7 @@ To avoid external dependencies like Gitpod and a Jira Cloud instance, use the [J
    ```
 
 1. Restart GDK.
-1. Go to `http://127.0.0.1:3000/-/profile/personal_access_tokens`.
+1. Go to `http://127.0.0.1:3000/-/user_settings/personal_access_tokens`.
 1. Create a new token with the `api` scope and copy the token.
 1. Go to `http://localhost:9292`.
 1. Paste the token and select **Install GitLab.com Jira Cloud app**.
diff --git a/doc/development/push_rules/index.md b/doc/development/push_rules/index.md
new file mode 100644
index 00000000000..343b199e613
--- /dev/null
+++ b/doc/development/push_rules/index.md
@@ -0,0 +1,93 @@
+---
+stage: Create
+group: Source Code
+info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
+---
+
+# Push Rules development guidelines
+
+This document was created to help contributors understand the code design of
+[Push Rules](../../user/project/repository/push_rules.md). You should read this
+document before making changes to the code for this feature.
+
+This document is intentionally limited to an overview of how the code is
+designed, as code can change often. To understand how a specific part of the
+feature works, view the code and the specs. The details here explain how the
+major components of the Push Rules feature work.
+
+NOTE:
+This document should be updated when parts of the codebase referenced in this
+document are updated, removed, or new parts are added.
+
+## Business logic
+
+The business logic is contained in two main places. The `PushRule` model stores
+the settings for a rule and then we have checks that use those settings to
+change the push behavior.
+
+- `PushRule`: the main model used to store the configuration of each push rule.
+  - Defined in `ee/app/models/push_rule.rb`.
+- `EE::Gitlab::Checks::DiffCheck`: Diff check prevents filenames matching the
+  push rule's `file_name_regex` and also files with names matching known secret
+  files, for example `id_rsa`.
+  - Defined in `ee/lib/ee/gitlab/checks/diff_check.rb`.
+- `EE::Gitlab::Checks::PushRuleCheck`: Executes various push rule checks.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rule_check.rb`.
+- `EE::Gitlab::Checks::PushRules::BranchCheck`: Executes push rule checks
+  related to branch rules.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rules/branch_check.rb`.
+- `EE::Gitlab::Checks::PushRules::CommitCheck`: Executes push rule checks
+  related to commit rules.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rules/commit_check.rb`.
+- `EE::Gitlab::Checks::PushRules::FileSizeCheck`: Executes push rule checks
+  related to file size rules.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rules/file_size_check.rb`.
+- `EE::Gitlab::Checks::PushRules::SecretsCheck`: Executes push rule checks
+  related to secrets rules.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rules/secrets_check.rb`.
+- `EE::Gitlab::Checks::PushRules::TagCheck`: Executes push rule checks
+  related to tag rules.
+  - Defined in `ee/lib/ee/gitlab/checks/push_rules/tag_check.rb`.
+
+## Entrypoints
+
+The following controllers and APIs are all entrypoints into the push rules logic:
+
+- `Admin::PushRulesController`: This controller is used to manage the global push rule.
+- `Group::PushRulesController`: This controller is used to manage the group-level push rule.
+- `Project::PushRulesController`: This controller is used to manage the project-level push rule.
+- `Api::Internal::Base`: This `/internal/allowed` endpoint is called when pushing to GitLab over SSH to
+  ensure the user is allowed to push. The `/internal/allowed` endpoint performs a
+  `Gitlab::Checks::DiffCheck`. In EE, this includes push rules checks.
+  - Defined in `lib/api/internal/base.rb`.
+- `Repositories::GitHttpController`: When changes are pushed to GitLab over HTTP, the controller performs an access
+  check to ensure the user is allowed to push. The checks perform a
+  `Gitlab::Checks::DiffCheck`. In EE, this includes push rules checks.
+  - Defined in `app/controllers/repositories/git_http_controller.rb`.
+
+## Flow
+
+These flowcharts should help explain the flow from the controllers down to the
+models for different features.
+
+### Git push over SSH
+
+```mermaid
+graph TD
+  Repositories::GitHttpController --> Gitlab::GitAccess
+  Api::Internal::Base --> Gitlab::GitAccess
+  Gitlab::GitAccess --> Gitlab::Checks::ChangesAccess
+  Gitlab::Checks::ChangesAccess --> Gitlab::Checks::SingleChangeAccess
+  Gitlab::Checks::ChangesAccess --> EE::Gitlab::Checks::PushRuleCheck
+  Gitlab::Checks::SingleChangeAccess --> Gitlab::Checks::DiffCheck
+  EE::Gitlab::Checks::PushRuleCheck -->|Only if pushing to a tag| EE::Gitlab::Checks::PushRules::TagCheck
+  EE::Gitlab::Checks::PushRuleCheck -->|Only if pushing to a branch| EE::Gitlab::Checks::PushRules::BranchCheck
+  EE::Gitlab::Checks::PushRuleCheck --> EE::Gitlab::Checks::PushRules::FileSizeCheck
+  EE::Gitlab::Checks::PushRuleCheck --> EE::Gitlab::Checks::PushRules::SecretsCheck
+  EE::Gitlab::Checks::PushRuleCheck --> EE::Gitlab::Checks::PushRules::SecretsCheck
+```
+
+NOTE:
+The `PushRuleCheck` only triggers checks in parallel if the
+`parallel_push_checks` feature flag is enabled. Otherwise tag or branch check
+runs first, then file size, then secrets.
diff --git a/doc/development/sec/generate_test_vulnerabilities.md b/doc/development/sec/generate_test_vulnerabilities.md
index 59fa0d905df..d862ee91c83 100644
--- a/doc/development/sec/generate_test_vulnerabilities.md
+++ b/doc/development/sec/generate_test_vulnerabilities.md
@@ -10,7 +10,7 @@ You can generate test vulnerabilities for the [Vulnerability Report](../../user/
 vulnerability management features without running a pipeline.
 
 1. Log in to GitLab.
-1. Go to `/-/profile/personal_access_tokens` and generate a personal access token with `api` permissions.
+1. Go to `/-/user_settings/personal_access_tokens` and generate a personal access token with `api` permissions.
 1. Go to your project page and find the project ID. You can find the project ID below the project title.
 1. [Clone the GitLab repository](../../gitlab-basics/start-using-git.md#clone-a-repository) to your local machine.
 1. Open a terminal and go to `gitlab/qa` directory.
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index 341d7460f83..034e2e45127 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -78,7 +78,8 @@ When you mention a group in a comment, every member of the group gets a to-do it
 added to their To-do list.
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Issues** or **Merge requests**, and find your issue or merge request.
+1. For merge requests, select **Code > Merge requests**, and find your merge request.
+1. For issues, select **Plan > Issues**, and find your issue.
 1. In a comment, type `@` followed by the user, group, or subgroup namespace.
    For example, `@alex`, `@alex-team`, or `@alex-team/marketing`.
 1. Select **Comment**.
@@ -98,7 +99,7 @@ persist, even when you:
 To add a commit diff comment:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests**, and find your merge request.
+1. Select **Code > Merge requests**, and find your merge request.
 1. Select the **Commits** tab, then select the commit message.
 1. By the line you want to comment on, hover over the line number and select **Comment** (**{comment}**).
    You can select multiple lines by dragging the **Comment** (**{comment}**) icon.
@@ -160,7 +161,8 @@ Prerequisites:
 To lock an issue or merge request:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Issues** or **Merge requests**, and find your issue or merge request.
+1. For merge requests, select **Code > Merge requests**, and find your merge request.
+1. For issues, select **Plan > Issues**, and find your issue.
 1. On the top right, select **Merge request actions** or **Issue actions** (**{ellipsis_v}**), then select **Lock discussion**.
 
 A system note is added to the page details.
diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md
index 1f4352ea805..ac6ec4ce2f0 100644
--- a/doc/user/profile/personal_access_tokens.md
+++ b/doc/user/profile/personal_access_tokens.md
@@ -68,7 +68,7 @@ list of scopes. To do this, you can append a `name` parameter and a list of comm
 to the URL. For example:
 
 ```plaintext
-https://gitlab.example.com/-/profile/personal_access_tokens?name=Example+Access+token&scopes=api,read_user,read_registry
+https://gitlab.example.com/-/user_settings/personal_access_tokens?name=Example+Access+token&scopes=api,read_user,read_registry
 ```
 
 WARNING:
diff --git a/doc/user/project/merge_requests/changes.md b/doc/user/project/merge_requests/changes.md
index 513010b01e2..780041ac411 100644
--- a/doc/user/project/merge_requests/changes.md
+++ b/doc/user/project/merge_requests/changes.md
@@ -24,7 +24,7 @@ in our development documentation.
 To view the diff of changes included in a merge request:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the merge request title, select **Changes**.
 1. If the merge request changes many files, you can jump directly to a specific file:
    1. Select **Show file browser** (**{file-tree}**) or press <kbd>F</kbd> to display the file tree.
@@ -45,7 +45,7 @@ so it [applies to all merge requests](#in-all-merge-requests-show-only-one-file-
 To temporarily change your viewing preferences for a specific merge request:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the merge request title, select **Changes**.
 1. Select **Preferences** (**{settings}**).
 1. Select or clear the **Show one file at a time** checkbox.
@@ -73,7 +73,7 @@ merge requests. To view other changed files, either:
 You can view the changes inline:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. Select **Preferences** (**{settings}**).
 1. In the **Compare changes** area, select **Inline**.
@@ -88,7 +88,7 @@ Depending on the length of the changes in your merge request, you might find it
 easier to view the changes inline, or side-by-side:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. Select **Preferences** (**{settings}**).
 1. In the **Compare changes** area, select **Side-by-side**.
@@ -102,7 +102,7 @@ The changes are displayed across from one another.
 When reviewing code changes, you can hide inline comments:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. Scroll to the file that contains the comments you want to hide.
 1. Scroll to the line the comment is attached to, and select **Collapse** (**{collapse}**):
@@ -111,7 +111,7 @@ When reviewing code changes, you can hide inline comments:
 To expand inline comments and show them again:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. Scroll to the file that contains the collapsed comments you want to show.
 1. Scroll to the line the comment is attached to, and select the user avatar:
@@ -123,7 +123,7 @@ Whitespace changes can make it more difficult to see the substantive changes in
 a merge request. You can choose to hide or show whitespace changes:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. Before the list of changed files, select **Preferences** (**{settings}**).
 1. Select or clear the **Show whitespace changes** checkbox:
@@ -139,7 +139,7 @@ When reviewing a merge request with many files multiple times, you can ignore fi
 you've already reviewed. To hide files that haven't changed since your last review:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find your merge request.
+1. Select **Code > Merge requests** and find your merge request.
 1. Below the title, select **Changes**.
 1. In the file's header, select the **Viewed** checkbox.
 
diff --git a/doc/user/project/merge_requests/confidential.md b/doc/user/project/merge_requests/confidential.md
index 72fa836e60c..1067beef909 100644
--- a/doc/user/project/merge_requests/confidential.md
+++ b/doc/user/project/merge_requests/confidential.md
@@ -46,7 +46,7 @@ Prerequisites:
 To create a confidential merge request:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Issues** and find the issue you want to create a merge request for.
+1. Select **Plan > Issues** and find the issue you want to create a merge request for.
 1. Scroll below the issue description, and select **Create confidential merge request**.
 1. Select the item that meets your needs:
    - *To create both a branch and a merge request,* select
diff --git a/doc/user/project/merge_requests/conflicts.md b/doc/user/project/merge_requests/conflicts.md
index f3fd38bdcef..53d1269a940 100644
--- a/doc/user/project/merge_requests/conflicts.md
+++ b/doc/user/project/merge_requests/conflicts.md
@@ -106,7 +106,7 @@ resolve their conflicts. The merge conflict resolution editor helps you resolve
 these complex conflicts in the GitLab interface:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Merge requests** and find the merge request.
+1. Select **Code > 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/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index 85874692725..951c848dee1 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -45,7 +45,7 @@ After merging the merge request, the issue is closed automatically, unless
 To create a branch and a merge request at the same time:
 
 1. On the left sidebar, select **Search or go to** and find your project.
-1. Select **Issues** and find your issue.
+1. Select **Plan > Issues** and find your issue.
 1. Go to the bottom of the issue description.
 1. Select **Create merge request > Create merge request and branch**.
 1. In the dialog, review the suggested branch name. It's based on your project's
diff --git a/doc/user/project/repository/signed_commits/index.md b/doc/user/project/repository/signed_commits/index.md
index 297ae31048e..cbea5e4e2f5 100644
--- a/doc/user/project/repository/signed_commits/index.md
+++ b/doc/user/project/repository/signed_commits/index.md
@@ -28,7 +28,7 @@ they are signed.
 1. To review commits:
    - For a project, select **Code > Commits**.
    - For a merge request:
-     1. Select **Merge requests**, then select your merge request.
+     1. Select **Code > Merge requests**, then select your merge request.
      1. Select **Commits**.
 1. Identify the commit you want to review. Signed commits show either a **Verified**
    or **Unverified** badge, depending on the verification status of the signature.