Add latest changes from gitlab-org/gitlab@master

12 files changed, 50 insertions, 30 deletions

diff --git a/doc/.vale/gitlab/Uppercase.yml b/doc/.vale/gitlab/Uppercase.yml
index 19e0fec6622..1948842d026 100644
--- a/doc/.vale/gitlab/Uppercase.yml
+++ b/doc/.vale/gitlab/Uppercase.yml
@@ -147,6 +147,7 @@ exceptions:
   - NPM
   - NTP
   - OCI
+  - OIDC
   - OKD
   - OKR
   - ONLY
diff --git a/doc/administration/geo/replication/single_sign_on.md b/doc/administration/geo/replication/single_sign_on.md
index fc2f23552db..55e77d5657c 100644
--- a/doc/administration/geo/replication/single_sign_on.md
+++ b/doc/administration/geo/replication/single_sign_on.md
@@ -112,6 +112,15 @@ After configuring your SAML IdP to allow the secondary site's SAML callback URL,
 
 If you have configured SAML on the primary site correctly, then it should work on the secondary site without additional configuration.
 
+## OpenID Connect
+
+If you use an [OpenID Connect (OIDC)](../../auth/oidc.md) OmniAuth provider,
+in most cases, it should work without an issue:
+
+- **OIDC with Unified URL**: If you have configured OIDC on the primary site correctly, then it should work on the secondary site without additional configuration.
+- **OIDC with separate URL with proxying disabled**: If you have configured OIDC on the primary site correctly, then it should work on the secondary site without additional configuration.
+- **OIDC with separate URL with proxying enabled**: Geo with separate URL with proxying enabled does not support [OpenID Connect](../../auth/oidc.md). For more information, see [issue 396745](https://gitlab.com/gitlab-org/gitlab/-/issues/396745).
+
 ## LDAP
 
 If you use LDAP on your **primary** site, you should also set up secondary LDAP servers on each **secondary** site. Otherwise, users cannot perform Git operations over HTTP(s) on the **secondary** site using HTTP basic authentication. However, users can still use Git with SSH and personal access tokens.
diff --git a/doc/ci/cloud_services/google_cloud/index.md b/doc/ci/cloud_services/google_cloud/index.md
index 97ea63f57e7..719b97c53d8 100644
--- a/doc/ci/cloud_services/google_cloud/index.md
+++ b/doc/ci/cloud_services/google_cloud/index.md
@@ -6,8 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Configure OpenID Connect with GCP Workload Identity Federation **(FREE)**
 
-WARNING:
-The `CI_JOB_JWT_V2` variable is under development [(alpha)](../../../policy/alpha-beta-support.md#experiment) and is not yet suitable for production use.
+NOTE:
+`CI_JOB_JWT_V2` was [deprecated in GitLab 15.9](../../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated)
+and is scheduled to be removed in GitLab 16.0. Use [ID tokens](../../yaml/index.md#id_tokens) instead.
 
 This tutorial demonstrates authenticating to Google Cloud from a GitLab CI/CD job
 using a JSON Web Token (JWT) token and Workload Identity Federation. This configuration
diff --git a/doc/ci/cloud_services/index.md b/doc/ci/cloud_services/index.md
index 88e7d88e22a..115488c3f73 100644
--- a/doc/ci/cloud_services/index.md
+++ b/doc/ci/cloud_services/index.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - `CI_JOB_JWT` variable for reading secrets from Vault [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207125) in GitLab 12.10.
 > - `CI_JOB_JWT_V2` variable to support additional OIDC providers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346737) in GitLab 14.7.
-> - [ID tokens](../yaml/index.md) to support any OIDC provider, including HashiCorp Vault, [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/356986) in GitLab 15.7.
+> - [ID tokens](../yaml/index.md#id_tokens) to support any OIDC provider, including HashiCorp Vault, [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/356986) in GitLab 15.7.
 
 GitLab CI/CD supports [OpenID Connect (OIDC)](https://openid.net/connect/faq/) to
 give your build and deployment jobs access to cloud credentials and services.
@@ -19,6 +19,10 @@ in the CI/CD job allowing you to follow a scalable and least-privilege security
 In GitLab 15.6 and earlier, you must use `CI_JOB_JWT_V2` instead of an ID token,
 but it is not customizable. In GitLab 14.6 an earlier you must use the `CI_JOB_JWT`, which has limited support.
 
+NOTE:
+`CI_JOB_JWT` and `CI_JOB_JWT_V2` were [deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated)
+and are scheduled to be removed in GitLab 16.0. Use [ID tokens](../yaml/index.md#id_tokens) instead.
+
 ## Requirements
 
 - Account on GitLab.
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index 6295c131fb9..f59bb8ed931 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -5,15 +5,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: tutorial
 ---
 
-# Authenticating and reading secrets with HashiCorp Vault **(PREMIUM)**
+# Authenticating and reading secrets with HashiCorp Vault (Deprecated) **(PREMIUM)**
 
 This tutorial demonstrates how to authenticate, configure, and read secrets with HashiCorp's Vault from GitLab CI/CD.
 
 NOTE:
-[GitLab Premium](https://about.gitlab.com/pricing/) supports read access to a
-HashiCorp Vault, and enables you to
-[use Vault secrets in a CI job](../../secrets/index.md#use-vault-secrets-in-a-ci-job).
-For more information, see [Using external secrets in CI](../../secrets/index.md).
+Authenticating with HashiCorp Vault by using `CI_JOB_JWT` was [deprecated in GitLab 15.9](../../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated)
+and the token is scheduled to be removed in GitLab 16.0. Use [ID tokens to authenticate with HashiCorp Vault](../../secrets/id_token_authentication.md#automatic-id-token-authentication-with-hashicorp-vault) instead.
 
 ## Requirements
 
diff --git a/doc/ci/secrets/index.md b/doc/ci/secrets/index.md
index fa8fe2a36a8..6966a6baadf 100644
--- a/doc/ci/secrets/index.md
+++ b/doc/ci/secrets/index.md
@@ -23,14 +23,7 @@ GitLab has selected [Vault by HashiCorp](https://www.vaultproject.io) as the
 first supported provider, and [KV-V2](https://developer.hashicorp.com/vault/docs/secrets/kv/kv-v2)
 as the first supported secrets engine.
 
-By default, GitLab authenticates using Vault's
-[JSON Web Token (JWT) authentication method](https://developer.hashicorp.com/vault/docs/auth/jwt#jwt-authentication), using
-the [JSON Web Token](https://gitlab.com/gitlab-org/gitlab/-/issues/207125) (`CI_JOB_JWT`).
-
-[ID tokens](../yaml/index.md#id_tokens) is the preferred secure way to authenticate with Vault,
-because ID tokens are defined per-job. GitLab can also authenticate with Vault by using the `CI_JOB_JWT`,
-but that token is provided to every job, which can be a security risk.
-
+Use [ID tokens](../yaml/index.md#id_tokens) to [authenticate with Vault](https://developer.hashicorp.com/vault/docs/auth/jwt#jwt-authentication).
 The [Authenticating and Reading Secrets With HashiCorp Vault](../examples/authenticating-with-hashicorp-vault/index.md)
 tutorial has more details about authenticating with ID tokens.
 
@@ -40,7 +33,7 @@ can use [use Vault secrets in a CI job](#use-vault-secrets-in-a-ci-job).
 The flow for using GitLab with HashiCorp Vault
 is summarized by this diagram:
 
-![Flow between GitLab and HashiCorp](../img/gitlab_vault_workflow_v13_4.png "How GitLab CI_JOB_JWT works with HashiCorp Vault")
+![Flow between GitLab and HashiCorp](../img/gitlab_vault_workflow_v13_4.png "How GitLab authenticates with HashiCorp Vault")
 
 1. Configure your vault and secrets.
 1. Generate your JWT and provide it to your CI job.
diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md
index 515c7b13d4a..64a0f1038ad 100644
--- a/doc/ci/variables/index.md
+++ b/doc/ci/variables/index.md
@@ -469,7 +469,8 @@ To pass a job-created environment variable to other jobs:
    - Values can be wrapped in quotes, but cannot contain newline characters.
 1. Save the `.env` file as an [`artifacts:reports:dotenv`](../yaml/artifacts_reports.md#artifactsreportsdotenv)
    artifact.
-1. Jobs in later stages can then [use the variable in scripts](#use-cicd-variables-in-job-scripts).
+1. Jobs in later stages can then [use the variable in scripts](#use-cicd-variables-in-job-scripts),
+   unless [jobs are configured not to receive `dotenv` variables](#control-which-jobs-receive-dotenv-variables).
 
 For example:
 
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index 5c298882d31..3de36479de7 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -68,9 +68,9 @@ as it can cause the pipeline to behave unexpectedly.
 | `CI_HAS_OPEN_REQUIREMENTS`               | 13.1   | all    | Only available if the pipeline's project has an open [requirement](../../user/project/requirements/index.md). `true` when available. |
 | `CI_JOB_ID`                              | 9.0    | all    | The internal ID of the job, unique across all jobs in the GitLab instance. |
 | `CI_JOB_IMAGE`                           | 12.9   | 12.9   | The name of the Docker image running the job. |
-| `CI_JOB_JWT`                             | 12.10  | all    | A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example [HashiCorp's Vault](../secrets/index.md). |
-| `CI_JOB_JWT_V1`                          | 14.6   | all    | The same value as `CI_JOB_JWT`. |
-| `CI_JOB_JWT_V2`                          | 14.6   | all    | A newly formatted RS256 JSON web token to increase compatibility. Similar to `CI_JOB_JWT`, except the issuer (`iss`) claim is changed from `gitlab.com` to `https://gitlab.com`, `sub` has changed from `job_id` to a string that contains the project path, and an `aud` claim is added. Format is subject to change. Be aware, the `aud` field is a constant value. Trusting JWTs in multiple relying parties can lead to [one RP sending a JWT to another one and acting maliciously as a job](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72555#note_769112331). **Note:** The `CI_JOB_JWT_V2` variable is available for testing, but the full feature is planned to be generally available when [issue 360657](https://gitlab.com/gitlab-org/gitlab/-/issues/360657) is complete.|
+| `CI_JOB_JWT` (Deprecated)                | 12.10  | all    | A RS256 JSON web token to authenticate with third party systems that support JWT authentication, for example [HashiCorp's Vault](../secrets/index.md). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 16.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
+| `CI_JOB_JWT_V1` (Deprecated)             | 14.6   | all    | The same value as `CI_JOB_JWT`. [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 16.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
+| `CI_JOB_JWT_V2` (Deprecated)             | 14.6   | all    | A newly formatted RS256 JSON web token to increase compatibility. Similar to `CI_JOB_JWT`, except the issuer (`iss`) claim is changed from `gitlab.com` to `https://gitlab.com`, `sub` has changed from `job_id` to a string that contains the project path, and an `aud` claim is added. The `aud` field is a constant value. Trusting JWTs in multiple relying parties can lead to [one RP sending a JWT to another one and acting maliciously as a job](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72555#note_769112331). [Deprecated in GitLab 15.9](../../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and scheduled to be removed in GitLab 16.0. Use [ID tokens](../yaml/index.md#id_tokens) instead. |
 | `CI_JOB_MANUAL`                          | 8.12   | all    | Only available if the job was started manually. `true` when available. |
 | `CI_JOB_NAME`                            | 9.0    | 0.5    | The name of the job. |
 | `CI_JOB_NAME_SLUG`                       | 15.4   | all    | `CI_JOB_NAME_SLUG` in lowercase, shortened to 63 bytes, and with everything except `0-9` and `a-z` replaced with `-`. No leading / trailing `-`. Use in paths. |
diff --git a/doc/development/application_secrets.md b/doc/development/application_secrets.md
index 526cc6c3f61..e640a94f0a6 100644
--- a/doc/development/application_secrets.md
+++ b/doc/development/application_secrets.md
@@ -17,7 +17,7 @@ This page is a development guide for application secrets.
 |`db_key_base`                     | The base key to encrypt the data for `attr_encrypted` columns     |
 |`openid_connect_signing_key`      | The signing key for OpenID Connect                                |
 | `encrypted_settings_key_base`    | The base key to encrypt settings files with                       |
-| `ci_jwt_signing_key`             | The base key for encrypting the `CI_JOB_JWT` and `CI_JOB_JWT_V2` predefined CI/CD variables |
+| `ci_jwt_signing_key`             | The base key for encrypting the `CI_JOB_JWT` and `CI_JOB_JWT_V2` predefined CI/CD variables. `CI_JOB_JWT` and `CI_JOB_JWT_V2` were [deprecated in GitLab 15.9](../update/deprecations.md#old-versions-of-json-web-tokens-are-deprecated) and are scheduled to be removed in GitLab 16.0. |
 
 ## Where the secrets are stored
 
diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md
index e9d2a724d9d..a3ab1c1af30 100644
--- a/doc/development/fe_guide/style/vue.md
+++ b/doc/development/fe_guide/style/vue.md
@@ -650,6 +650,18 @@ over [`expect.objectContaining`](https://jestjs.io/docs/expect#expectobjectconta
    });
    ```
 
+### Testing props validation
+
+1. When checking component props use `assertProps` helper. Props validation failures will be thrown as errors
+
+```javascript
+import { assertProps } from 'helpers/assert_props'
+
+// ...
+
+expect(() => assertProps(SomeComponent, { invalidPropValue: '1', someOtherProp: 2 })).toThrow()
+```
+
 ## The JavaScript/Vue Accord
 
 The goal of this accord is to make sure we are all on the same page.
diff --git a/doc/integration/jira/configure.md b/doc/integration/jira/configure.md
index d6732321e7c..f1f7a34ac94 100644
--- a/doc/integration/jira/configure.md
+++ b/doc/integration/jira/configure.md
@@ -8,10 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 The Jira integration connects one or more GitLab projects to a Jira instance. You can host the Jira instance yourself or in [Atlassian Cloud](https://www.atlassian.com/migration/assess/why-cloud). The supported Jira versions are `6.x`, `7.x`, `8.x`, and `9.x`.
 
-You can set up the [Jira integration](index.md#jira-integration)
-by configuring your project settings in GitLab.
-You can also configure these settings at a [group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration),
-and for self-managed GitLab, at an [instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration).
+## Configure the integration
 
 Prerequisites:
 
@@ -22,9 +19,13 @@ Prerequisites:
   and the email address you used to create the token.
   See [authentication in Jira](index.md#authentication-in-jira).
 
-## Configure a project
+You can enable the Jira integration by configuring your project settings in GitLab.
+You can also configure these settings at the:
 
-To configure your project:
+- [Group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration)
+- [Instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration) for self-managed GitLab
+
+To configure your project settings in GitLab:
 
 1. On the top bar, select **Main menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > Integrations**.
diff --git a/doc/integration/jira/development_panel.md b/doc/integration/jira/development_panel.md
index 370b9178441..69394e2d445 100644
--- a/doc/integration/jira/development_panel.md
+++ b/doc/integration/jira/development_panel.md
@@ -8,8 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/233149) from GitLab Premium to GitLab Free in 13.4.
 
-The Jira development panel connects all GitLab projects in a group or personal namespace.
-You can view GitLab activity from the Jira development panel.
+The Jira development panel connects all GitLab projects in a group or personal namespace
+where you can view GitLab activity.
 
 When you're in GitLab, you can refer to a Jira issue by ID.
 The [activity for that issue](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/)