Add latest changes from gitlab-org/gitlab@master

16 files changed, 113 insertions, 122 deletions

diff --git a/doc/user/application_security/sast/customize_rulesets.md b/doc/user/application_security/sast/customize_rulesets.md
index d070883df9a..b45b25db69f 100644
--- a/doc/user/application_security/sast/customize_rulesets.md
+++ b/doc/user/application_security/sast/customize_rulesets.md
@@ -323,7 +323,7 @@ With the following custom ruleset configuration, vulnerabilities found with
 [semgrep]
   [[semgrep.ruleset]]
     [semgrep.ruleset.identifier]
-      type = "CWE"
+      type = "cwe"
       value = "322"
     [semgrep.ruleset.override]
       severity = "Critical"
diff --git a/doc/user/clusters/agent/ci_cd_workflow.md b/doc/user/clusters/agent/ci_cd_workflow.md
index abbcb533e7e..60c36b35b53 100644
--- a/doc/user/clusters/agent/ci_cd_workflow.md
+++ b/doc/user/clusters/agent/ci_cd_workflow.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Using GitLab CI/CD with a Kubernetes cluster **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327409) in GitLab 14.1.
-> - The pre-configured `KUBECONFIG` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) in GitLab 14.2.
+> - The pre-configured variable `$KUBECONFIG` [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) in GitLab 14.2.
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) the `ci_access` attribute in GitLab 14.3.
 > - The ability to authorize groups was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) to GitLab Free in 14.5.
@@ -78,7 +78,8 @@ To authorize the agent to access the GitLab project where you keep Kubernetes ma
    - You can install additional agents into the same cluster to accommodate additional hierarchies.
    - You can authorize up to 100 projects.
 
-All CI/CD jobs now include a `KUBECONFIG` with contexts for every shared agent connection.
+All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.
+The `kubeconfig` path is available in the environment variable `$KUBECONFIG`.
 Choose the context to run `kubectl` commands from your CI/CD scripts.
 
 ### Authorize the agent to access projects in your groups
@@ -104,7 +105,8 @@ To authorize the agent to access all of the GitLab projects in a group or subgro
    - You can authorize up to 100 groups.
 
 All the projects that belong to the group and its subgroups are now authorized to access the agent.
-All CI/CD jobs now include a `KUBECONFIG` with contexts for every shared agent connection.
+All CI/CD jobs now include a `kubeconfig` file with contexts for every shared agent connection.
+The `kubeconfig` path is available in an environment variable `$KUBECONFIG`.
 Choose the context to run `kubectl` commands from your CI/CD scripts.
 
 ## Update your `.gitlab-ci.yml` file to run `kubectl` commands
@@ -159,10 +161,10 @@ When you deploy to an environment that has both a
 
 - The certificate-based cluster's context is called `gitlab-deploy`. This context
   is always selected by default.
-- In GitLab 14.9 and later, agent contexts are included in the
-  `KUBECONFIG`. You can select them by using `kubectl config use-context path/to/agent/repository:agent-name`.
+- In GitLab 14.9 and later, agent contexts are included in `$KUBECONFIG`.
+  You can select them by using `kubectl config use-context path/to/agent/repository:agent-name`.
 - In GitLab 14.8 and earlier, you can still use agent connections, but for environments that
-  already have a certificate-based cluster, the agent connections are not included in the `KUBECONFIG`.
+  already have a certificate-based cluster, the agent connections are not included in `$KUBECONFIG`.
 
 To use an agent connection when certificate-based connections are present, you can manually configure a new `kubectl`
 configuration context. For example:
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 1af95b06aa8..37f1f4cc65e 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -235,81 +235,6 @@ The certificate [fingerprint algorithm](../../../integration/saml.md#configure-s
 
 If you are having issues configuring GitLab, see the [troubleshooting documentation](#troubleshooting).
 
-### SSO enforcement
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5291) in GitLab 11.8.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/339888) in GitLab 14.7 to not enforce SSO checks for Git activity originating from CI/CD jobs.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/215155) in GitLab 15.5 [with a flag](../../../administration/feature_flags.md) named `transparent_sso_enforcement` to include transparent enforcement even when SSO enforcement is not enabled. Disabled on GitLab.com.
-> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) in GitLab 15.8 by enabling transparent SSO by default on GitLab.com.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/389562) in GitLab 15.10. Feature flag `transparent_sso_enforcement` removed.
-
-On GitLab.com, SSO is enforced:
-
-- When SAML SSO is enabled.
-- For users with an existing SAML identity when accessing groups and projects in the organization's
-  group hierarchy. Users can view other groups and projects as well as their user settings without SSO sign in by using their GitLab.com credentials.
-
-A user has a SAML identity if one or both of the following are true:
-
-- They have signed in to GitLab by using their GitLab group's single sign-on URL.
-- They were provisioned by SCIM.
-
-Users are not prompted to sign in through SSO on each visit. GitLab checks
-whether a user has authenticated through SSO. If the user last signed in more
-than 24 hours ago, GitLab prompts the user to sign in again through SSO.
-
-SSO is enforced as follows:
-
-| Project/Group visibility | Enforce SSO setting | Member with identity | Member without identity | Non-member or not signed in |
-|--------------------------|---------------------|--------------------| ------ |------------------------------|
-| Private                  | Off                 | Enforced           | Not enforced | No access                    |
-| Private                  | On            | Enforced           | Enforced | No access                    |
-| Public                   | Off                 | Enforced           | Not enforced | Not enforced                 |
-| Public                   | On            | Enforced           | Enforced | Not enforced                 |
-
-An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity.
-
-#### SSO-only for web activity enforcement
-
-When the **Enforce SSO-only authentication for web activity for this group** option is enabled:
-
-- All users must access GitLab by using their GitLab group's single sign-on URL
-  to access group resources, regardless of whether they have an existing SAML
-  identity.
-- SSO is enforced when users access groups and projects in the organization's
-  group hierarchy. Users can view other groups and projects without SSO sign in.
-- Users cannot be added as new members manually.
-- Users with the Owner role can use the standard sign in process to make
-  necessary changes to top-level group settings.
-
-SSO enforcement for web activity has the following effects when enabled:
-
-- For groups, users cannot share a project in the group outside the top-level
-  group, even if the project is forked.
-- Git activity originating from CI/CD jobs do not have the SSO check enforced.
-- Credentials that are not tied to regular users (for example, project and group
-  access tokens, and deploy keys) do not have the SSO check enforced.
-- Users must be signed-in through SSO before they can pull images using the
-  [Dependency Proxy](../../packages/dependency_proxy/index.md).
-- When the **Enforce SSO-only authentication for Git and Dependency Proxy
-  activity for this group** option is enabled, any API endpoint that involves
-  Git activity is under SSO enforcement. For example, creating or deleting a
-  branch, commit, or tag. For Git activity over SSH and HTTPS, users must
-  have at least one active session signed-in through SSO before they can push to or
-  pull from a GitLab repository.
-
-When SSO for web activity is enforced, non-SSO group members do not lose access
-immediately. If the user:
-
-- Has an active session, they can continue accessing the group for up to 24
-  hours until the identity provider session times out.
-- Is signed out, they cannot access the group after being removed from the
-  identity provider.
-
 ## User access and management
 
 > - SAML user provisioning [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268142) in GitLab 13.7.
@@ -478,10 +403,6 @@ For example, to unlink the `MyOrg` account:
 
 For information on automatically managing GitLab group membership, see [SAML Group Sync](group_sync.md).
 
-## Passwords for users created via SAML SSO for Groups
-
-The [Generated passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via SAML SSO for Groups.
-
 ## NameID
 
 GitLab.com uses the SAML **NameID** to identify users. The **NameID** is:
@@ -517,16 +438,87 @@ requires a different format.
 
 You can use any format except `Transient`.
 
-## Related topics
+## SSO enforcement
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5291) in GitLab 11.8.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/292811) in GitLab 13.8, with an updated timeout experience.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/211962) in GitLab 13.8 with allowing group owners to not go through SSO.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/9152) in GitLab 13.11 with enforcing open SSO session to use Git if this setting is switched on.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/339888) in GitLab 14.7 to not enforce SSO checks for Git activity originating from CI/CD jobs.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/215155) in GitLab 15.5 [with a flag](../../../administration/feature_flags.md) named `transparent_sso_enforcement` to include transparent enforcement even when SSO enforcement is not enabled. Disabled on GitLab.com.
+> - [Improved](https://gitlab.com/gitlab-org/gitlab/-/issues/375788) in GitLab 15.8 by enabling transparent SSO by default on GitLab.com.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/389562) in GitLab 15.10. Feature flag `transparent_sso_enforcement` removed.
+
+On GitLab.com, SSO is enforced:
+
+- When SAML SSO is enabled.
+- For users with an existing SAML identity when accessing groups and projects in the organization's
+  group hierarchy. Users can view other groups and projects as well as their user settings without SSO sign in by using their GitLab.com credentials.
+
+A user has a SAML identity if one or both of the following are true:
+
+- They have signed in to GitLab by using their GitLab group's single sign-on URL.
+- They were provisioned by SCIM.
+
+Users are not prompted to sign in through SSO on each visit. GitLab checks
+whether a user has authenticated through SSO. If the user last signed in more
+than 24 hours ago, GitLab prompts the user to sign in again through SSO.
+
+SSO is enforced as follows:
+
+| Project/Group visibility | Enforce SSO setting | Member with identity | Member without identity | Non-member or not signed in |
+|--------------------------|---------------------|--------------------| ------ |------------------------------|
+| Private                  | Off                 | Enforced           | Not enforced | No access                    |
+| Private                  | On            | Enforced           | Enforced | No access                    |
+| Public                   | Off                 | Enforced           | Not enforced | Not enforced                 |
+| Public                   | On            | Enforced           | Enforced | Not enforced                 |
+
+An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity.
 
-For more information on:
+### SSO-only for web activity enforcement
+
+When the **Enforce SSO-only authentication for web activity for this group** option is enabled:
+
+- All users must access GitLab by using their GitLab group's single sign-on URL
+  to access group resources, regardless of whether they have an existing SAML
+  identity.
+- SSO is enforced when users access groups and projects in the organization's
+  group hierarchy. Users can view other groups and projects without SSO sign in.
+- Users cannot be added as new members manually.
+- Users with the Owner role can use the standard sign in process to make
+  necessary changes to top-level group settings.
+
+SSO enforcement for web activity has the following effects when enabled:
+
+- For groups, users cannot share a project in the group outside the top-level
+  group, even if the project is forked.
+- Git activity originating from CI/CD jobs do not have the SSO check enforced.
+- Credentials that are not tied to regular users (for example, project and group
+  access tokens, and deploy keys) do not have the SSO check enforced.
+- Users must be signed-in through SSO before they can pull images using the
+  [Dependency Proxy](../../packages/dependency_proxy/index.md).
+- When the **Enforce SSO-only authentication for Git and Dependency Proxy
+  activity for this group** option is enabled, any API endpoint that involves
+  Git activity is under SSO enforcement. For example, creating or deleting a
+  branch, commit, or tag. For Git activity over SSH and HTTPS, users must
+  have at least one active session signed-in through SSO before they can push to or
+  pull from a GitLab repository.
+
+When SSO for web activity is enforced, non-SSO group members do not lose access
+immediately. If the user:
+
+- Has an active session, they can continue accessing the group for up to 24
+  hours until the identity provider session times out.
+- Is signed out, they cannot access the group after being removed from the
+  identity provider.
+
+## Related topics
 
-- Setting up SAML on self-managed GitLab instances, see
-  [SAML SSO for self-managed GitLab instances](../../../integration/saml.md).
-- Commonly-used terms, see the
-  [glossary of common terms](../../../integration/saml.md#glossary-of-common-terms).
-- The differences between SaaS and self-managed authentication and authorization,
-  see the [SaaS vs. Self-Managed comparison](../../../administration/auth/index.md#saas-vs-self-managed-comparison).
+- [SAML SSO for self-managed GitLab instances](../../../integration/saml.md)
+- [Glossary of common terms](../../../integration/saml.md#glossary-of-common-terms)
+- [Authentication comparison between SaaS and self-managed](../../../administration/auth/index.md#saas-vs-self-managed-comparison)
+- [Passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md)
 
 ## Troubleshooting
 
diff --git a/doc/user/infrastructure/iac/terraform_state.md b/doc/user/infrastructure/iac/terraform_state.md
index 3935bfd9a86..87404699ad7 100644
--- a/doc/user/infrastructure/iac/terraform_state.md
+++ b/doc/user/infrastructure/iac/terraform_state.md
@@ -338,6 +338,5 @@ You can also use [the GraphQL API](../../../api/graphql/reference/index.md#mutat
 
 ## Related topics
 
-- [Troubleshooting GitLab-managed Terraform state](troubleshooting.md).
-- To use GitLab and Terraform to deploy an AWS EC2 instance in a custom VPC,
-  see [this sample project](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws).
+- [Troubleshooting GitLab-managed Terraform state](troubleshooting.md)
+- [Sample project: Terraform deployment of AWS EC2 instance in a custom VPC](https://gitlab.com/gitlab-org/configure/examples/gitlab-terraform-aws)
diff --git a/doc/user/packages/yarn_repository/index.md b/doc/user/packages/yarn_repository/index.md
index e756a912928..c8f4985a518 100644
--- a/doc/user/packages/yarn_repository/index.md
+++ b/doc/user/packages/yarn_repository/index.md
@@ -302,10 +302,8 @@ Then you can use `yarn add` to install your packages.
 
 ## Related topics
 
-- For full helpful hints information, see the
-  [npm documentation](../npm_registry/index.md#helpful-hints).
-- For Yarn 1 to Yarn 2+ migration information see the
-  [Yarn Migration Guide](https://yarnpkg.com/getting-started/migration).
+- [npm documentation](../npm_registry/index.md#helpful-hints)
+- [Yarn Migration Guide](https://yarnpkg.com/getting-started/migration)
 
 ## Troubleshooting
 
diff --git a/doc/user/project/changelogs.md b/doc/user/project/changelogs.md
index a64edd053b1..8410655c244 100644
--- a/doc/user/project/changelogs.md
+++ b/doc/user/project/changelogs.md
@@ -313,5 +313,5 @@ an error is produced when generating a changelog.
 
 ## Related topics
 
-- [Changelog-related endpoints](../../api/repositories.md) in the Repositories API.
-- Developer documentation for [changelog entries](../../development/changelog.md) in GitLab.
+- [Changelog-related endpoints](../../api/repositories.md) in the Repositories API
+- Developer documentation for [changelog entries](../../development/changelog.md) in GitLab
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index 92fdc59dde3..6aac0dba63d 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -86,7 +86,6 @@ Prerequisites:
 1. Complete the fields.
 1. Optional. To grant `read-write` permission, select the **Grant write permissions to this key**
    checkbox.
-1. Optional. Update the **Expiration date**.
 
 A project deploy key is enabled when it is created. You can modify only a project deploy key's
 name and permissions.
diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md
index 9937ea956c4..28ad1f22b8d 100644
--- a/doc/user/project/import/bitbucket_server.md
+++ b/doc/user/project/import/bitbucket_server.md
@@ -132,5 +132,4 @@ Consider memory constraints on the system before deciding to increase `SIDEKIQ_M
 
 ## Related topics
 
-For information on automating user, group, and project import API calls, see
-[Automate group and project import](index.md#automate-group-and-project-import).
+- [Automate group and project import](index.md#automate-group-and-project-import)
diff --git a/doc/user/project/import/gitlab_com.md b/doc/user/project/import/gitlab_com.md
index c00709d9697..9cb3ff75d5d 100644
--- a/doc/user/project/import/gitlab_com.md
+++ b/doc/user/project/import/gitlab_com.md
@@ -33,7 +33,5 @@ When the importer is done, a new GitLab project is created with your imported da
 
 ## Related topics
 
-- To automate user, group, and project import API calls, see
-  [Automate group and project import](index.md#automate-group-and-project-import).
-- To import Wiki and merge request data to your new instance,
-  see [exporting a project](../settings/import_export.md#export-a-project-and-its-data).
+- [Automate group and project import](index.md#automate-group-and-project-import)
+- [Export a project](../settings/import_export.md#export-a-project-and-its-data)
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index da0546b85e6..1512039fb25 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -179,8 +179,6 @@ Your project's visibility is set to **Private** by default. To change project vi
 
 ## Related topics
 
-- For a list of words that you cannot use as project names, see
-  [reserved project and group names](../../user/reserved_names.md).
-- For a list of characters that you cannot use in project and group names, see
-  [limitations on project and group names](../../user/reserved_names.md#limitations-on-project-and-group-names).
-- [Manage projects](working_with_projects.md).
+- [Reserved project and group names](../../user/reserved_names.md)
+- [Limitations on project and group names](../../user/reserved_names.md#limitations-on-project-and-group-names)
+- [Manage projects](working_with_projects.md)
diff --git a/doc/user/project/integrations/microsoft_teams.md b/doc/user/project/integrations/microsoft_teams.md
index fc5d4d3cc80..fc448382cb4 100644
--- a/doc/user/project/integrations/microsoft_teams.md
+++ b/doc/user/project/integrations/microsoft_teams.md
@@ -58,4 +58,4 @@ GitLab to send the notifications:
 
 ## Related topics
 
-- [Setting up an incoming webhook on Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using#setting-up-a-custom-incoming-webhook).
+- [Setting up an incoming webhook on Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/connectors-using#setting-up-a-custom-incoming-webhook)
diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md
index 1ab564c108b..2a11236f9f0 100644
--- a/doc/user/project/merge_requests/approvals/settings.md
+++ b/doc/user/project/merge_requests/approvals/settings.md
@@ -140,7 +140,7 @@ However, approvals are reset if the target branch is changed.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90578) in GitLab 15.3.
 
-If you only want to remove approvals by Code Owners whose files have been changed:
+If you only want to remove approvals by Code Owners whose files have been changed when a commit is added:
 
 Prerequisite:
 
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 f0359446b06..102a2ad1c14 100644
--- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
+++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md
@@ -147,3 +147,11 @@ merge-request-pipeline-job:
 Instead, use branch (`push`) pipelines or merge request pipelines, when possible.
 For details on avoiding two pipelines for a single merge request, read the
 [`rules` documentation](../../../ci/jobs/job_control.md#avoid-duplicate-pipelines).
+
+### Merged results pipeline allows merge, despite a failed branch pipeline
+
+When [the **Pipelines must succeed** setting](#require-a-successful-pipeline-for-merge)
+is combined with
+[the **Merged results pipelines** feature](../../../ci/pipelines/merged_results_pipelines.md),
+failed branch pipeline may be ignored.
+[Issue 385841](https://gitlab.com/gitlab-org/gitlab/-/issues/385841) is open to track this.
diff --git a/doc/user/project/system_notes.md b/doc/user/project/system_notes.md
index 55c02228dde..236f649460b 100644
--- a/doc/user/project/system_notes.md
+++ b/doc/user/project/system_notes.md
@@ -53,4 +53,4 @@ The filtering options are:
 
 ## Related topics
 
-- The [Notes API](../../api/notes.md) can add system notes to objects in GitLab.
+- [Notes API](../../api/notes.md)
diff --git a/doc/user/public_access.md b/doc/user/public_access.md
index 87380ec324e..58eebc16d74 100644
--- a/doc/user/public_access.md
+++ b/doc/user/public_access.md
@@ -95,8 +95,7 @@ For more information, see [Restrict visibility levels](admin_area/settings/visib
 
 ## Related topics
 
-- For more granular control of project features, you can
-  [change the visibility of features](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project).
+- [Change the visibility of features](project/working_with_projects.md#change-the-visibility-of-individual-features-in-a-project)
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/report_abuse.md b/doc/user/report_abuse.md
index a20a699e550..de2b82c28d3 100644
--- a/doc/user/report_abuse.md
+++ b/doc/user/report_abuse.md
@@ -66,5 +66,4 @@ A URL to the reported user's comment is pre-filled in the abuse report's
 
 ## Related topics
 
-- Administrators can view and resolve abuse reports.
-  For more information, see [abuse reports administration documentation](admin_area/review_abuse_reports.md).
+- [Abuse reports administration documentation](admin_area/review_abuse_reports.md)