Add latest changes from gitlab-org/gitlab@master

10 files changed, 107 insertions, 50 deletions

diff --git a/doc/administration/audit_event_streaming/index.md b/doc/administration/audit_event_streaming/index.md
index 2c3ec2aafc3..b9e747d2725 100644
--- a/doc/administration/audit_event_streaming/index.md
+++ b/doc/administration/audit_event_streaming/index.md
@@ -49,7 +49,7 @@ To add streaming destinations to a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select **Add streaming destination** and select **HTTP endpoint** to show the section for adding destinations.
 1. In the **Name** and **Destination URL** fields, add a destination name and URL.
 1. Optional. Locate the **Custom HTTP headers** table.
@@ -68,7 +68,7 @@ To list the streaming destinations for a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand it and see all the custom HTTP headers.
 
 #### Update an HTTP destination
@@ -81,7 +81,7 @@ To update a streaming destination's name:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. In the **Name** fields, add a destination name to update.
 1. Select **Save** to update the streaming destination.
@@ -90,7 +90,7 @@ To update a streaming destination's custom HTTP headers:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. Locate the **Custom HTTP headers** table.
 1. Locate the header that you wish to update.
@@ -146,7 +146,7 @@ To list streaming destinations and see the verification tokens:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select the **Streams**.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. Locate the **Verification token** input.
 
@@ -204,7 +204,7 @@ To add Google Cloud Logging streaming destinations to a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select **Add streaming destination** and select **Google Cloud Logging** to show the section for adding destinations.
 1. Enter a random string to use as a name for the new destination.
 1. Enter the Google project ID, Google client email, and Google private key from previously-created Google Cloud service account key to add to the new destination.
@@ -221,7 +221,7 @@ To list Google Cloud Logging streaming destinations for a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the Google Cloud Logging stream to expand and see all the fields.
 
 #### Update a Google Cloud Logging destination
@@ -236,7 +236,7 @@ To update Google Cloud Logging streaming destinations to a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the Google Cloud Logging stream to expand.
 1. Enter a random string to use as a name for the destination.
 1. Enter the Google project ID and Google client email from previously-created Google Cloud service account key to update the destination.
@@ -284,7 +284,7 @@ To add AWS S3 streaming destinations to a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select **Add streaming destination** and select **AWS S3** to show the section for adding destinations.
 1. Enter a random string to use as a name for the new destination.
 1. Enter the Access Key ID, Secret Access Key, Bucket Name, and AWS Region from previously-created AWS access key and bucket to add to the new destination.
@@ -300,7 +300,7 @@ To list AWS S3 streaming destinations for a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the AWS S3 stream to expand and see all the fields.
 
 #### Update a AWS S3 destination
@@ -313,7 +313,7 @@ To update AWS S3 streaming destinations to a top-level group:
 
 1. On the left sidebar, select **Search or go to** and find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
+1. On the main area, select the **Streams** tab.
 1. Select the AWS S3 stream to expand.
 1. Enter a random string to use as a name for the destination.
 1. Enter the Access Key ID, Secret Access Key, Bucket Name, and AWS Region from previously-created AWS access key and bucket to update the destination.
@@ -358,8 +358,8 @@ Prerequisites:
 To add a streaming destination for an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select **Add streaming destination** and select **HTTP endpoint** to show the section for adding destinations.
 1. In the **Name** and **Destination URL** fields, add a destination name and URL.
 1. Optional. To add custom HTTP headers, select **Add header** to create a new name and value pair, and input their values. Repeat this step for as many name and value pairs are required. You can add up to 20 headers per streaming destination.
@@ -377,8 +377,8 @@ Prerequisites:
 To list the streaming destinations for an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand it and see all the custom HTTP headers.
 
 #### Update an HTTP destination
@@ -390,8 +390,8 @@ Prerequisites:
 To update a instance streaming destination's name:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. In the **Name** fields, add a destination name to update.
 1. Select **Save** to update the streaming destination.
@@ -399,8 +399,8 @@ To update a instance streaming destination's name:
 To update a instance streaming destination's custom HTTP headers:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. Locate the **Custom HTTP headers** table.
 1. Locate the header that you wish to update.
@@ -421,7 +421,7 @@ Prerequisites:
 To delete the streaming destinations for an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
+1. Select **Monitoring > Audit Events**.
 1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. Select **Delete destination**.
@@ -430,7 +430,7 @@ To delete the streaming destinations for an instance:
 To delete only the custom HTTP headers for a streaming destination:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
+1. Select **Monitoring > Audit Events**.
 1. On the main area, select the **Streams** tab.
 1. To the right of the item, **Edit** (**{pencil}**).
 1. Locate the **Custom HTTP headers** table.
@@ -457,7 +457,7 @@ Prerequisites:
 To list streaming destinations for an instance and see the verification tokens:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
+1. Select **Monitoring > Audit Events**.
 1. On the main area, select the **Streams** tab.
 1. View the verification token on the right side of each item.
 
@@ -473,7 +473,7 @@ A streaming destination that has an event type filter set has a **filtered** (**
 To update a streaming destination's event filters:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
+1. Select **Monitoring > Audit Events**.
 1. On the main area, select the **Streams** tab.
 1. Select the stream to expand.
 1. Locate the **Filter by audit event type** dropdown list.
@@ -514,8 +514,8 @@ Prerequisites:
 To add Google Cloud Logging streaming destinations to an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select **Add streaming destination** and select **Google Cloud Logging** to show the section for adding destinations.
 1. Enter a random string to use as a name for the new destination.
 1. Enter the Google project ID, Google client email, and Google private key from previously-created Google Cloud service account key to add to the new destination.
@@ -531,8 +531,8 @@ Prerequisites:
 To list Google Cloud Logging streaming destinations for an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the Google Cloud Logging stream to expand and see all the fields.
 
 #### Update a Google Cloud Logging destination
@@ -544,8 +544,8 @@ Prerequisites:
 To update Google Cloud Logging streaming destinations to an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the Google Cloud Logging stream to expand.
 1. Enter a random string to use as a name for the destination.
 1. Enter the Google project ID and Google client email from previously-created Google Cloud service account key to update the destination.
@@ -562,8 +562,8 @@ Prerequisites:
 To delete Google Cloud Logging streaming destinations to an instance:
 
 1. On the left sidebar, at the bottom, select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+1. Select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
 1. Select the Google Cloud Logging stream to expand.
 1. Select **Delete destination**.
 1. Confirm by selecting **Delete destination** in the dialog.
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 471bae72c5b..6835231ab70 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -952,8 +952,7 @@ If you want to run the Geo tracking database on a single node, see [Configure th
 A production-ready and secure setup for the tracking PostgreSQL DB requires at least three Consul nodes: two
 Patroni nodes, and one PgBouncer node on the secondary site.
 
-Because of [issue 6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
-services, so these must be different than the nodes used for the Standby Cluster database.
+Consul can track multiple services, so you can choose to reuse the nodes used for the Standby Cluster database, though the instructions below do not show how to combine configurations when reusing Consul nodes.
 
 Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
 and other database best practices.
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index d37469a076a..64ec9b11763 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -502,6 +502,9 @@ To do that:
 1. Select the **Disable public access to Pages sites** checkbox.
 1. Select **Save changes**.
 
+NOTE:
+You must enable [Access Control](#access-control) first for the setting to show in the Admin Area.
+
 ### Running behind a proxy
 
 Like the rest of GitLab, Pages can be used in those environments where external
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 12bb8c3bc46..a1d68abc874 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -73,7 +73,7 @@ load of what each architecture has been tested against under the "Testing Method
 comparing those values with what load you are expecting against your existing GitLab environment to help select the right Reference Architecture
 size.
 
-Load is given in terms of Requests per Section (RPS) for each endpoint type (API, Web, Git). This information on your existing infrastructure
+Load is given in terms of Requests per Second (RPS) for each endpoint type (API, Web, Git). This information on your existing infrastructure
 can typically be surfaced by most reputable monitoring solutions or in some other ways such as load balancer metrics. For example, on existing GitLab environments,
 [Prometheus metrics](../monitoring/prometheus/gitlab_metrics.md) such as `gitlab_transaction_duration_seconds` can be used to see this data.
 
diff --git a/doc/architecture/blueprints/ai_gateway/index.md b/doc/architecture/blueprints/ai_gateway/index.md
index 79387152978..c09f8aaa621 100644
--- a/doc/architecture/blueprints/ai_gateway/index.md
+++ b/doc/architecture/blueprints/ai_gateway/index.md
@@ -86,6 +86,14 @@ The AI Gateway communication protocol shall only expect a rudimentary envelope t
  **This means
 that all clients regardless of their versions use the same set of AI-Gateway API feature endpoints. The AI-gateway feature endpoints have to support different client versions, instead of creating multiple feature endpoints per different supported client versions**.
 
+We can however add a version to the path in case we do want to evolve
+a certain endpoint. It's not expected that we'll need to do this
+often, but having a version in the path keeps the option open. The
+benefit of this is that individual GitLab milestone releases will
+continue pointing to the endpoint version it was tested against at the
+time of release, while allowing us to iterate quickly by introducing
+new endpoint versions.
+
 We also considered gRPC as a protocol for communication between
 GitLab instances, JSON API, and gRPC differ on these items:
 
@@ -263,7 +271,7 @@ A good practise that might help support backwards compatibility is to provide bu
 For example, a rough Code Suggestions service could look like this:
 
 ```plaintext
-POST /internal/code-suggestions/completions
+POST /v3/code/completions
 ```
 
 ```json
diff --git a/doc/ci/yaml/inputs.md b/doc/ci/yaml/inputs.md
index d32b949495c..a6c2497de3a 100644
--- a/doc/ci/yaml/inputs.md
+++ b/doc/ci/yaml/inputs.md
@@ -9,6 +9,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/391331) in GitLab 15.11 as a Beta feature.
 > - Made generally available in GitLab 16.6.
 
+Use inputs to increase the flexibility of CI/CD configuration files that are designed
+to be reused.
+
+Inputs can use CI/CD variables, but have the same [variable limitations as the `include` keyword](includes.md#use-variables-with-include).
+
 ## Define input parameters with `spec:inputs`
 
 Use `spec:inputs` to define input parameters for CI/CD configuration intended to be added
diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md
index a9289c53e92..0227eb8b8a9 100644
--- a/doc/update/versions/gitlab_16_changes.md
+++ b/doc/update/versions/gitlab_16_changes.md
@@ -16,6 +16,7 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f
 
 ## Issues to be aware of when upgrading from 15.11
 
+- [PostgreSQL 12 is not supported from v16](../../update/deprecations.md#postgresql-12-deprecated). Upgrade your PostgreSQL to at least 13.6 before upgrading to GitLab v16.0 or higher.
 - Some GitLab installations must upgrade to GitLab 16.0 before upgrading to any other version. For more information, see
   [Long-running user type data change](#long-running-user-type-data-change).
 - Other installations can skip 16.0, 16.1, and 16.2 as the first required stop on the upgrade path is 16.3. Review the notes for those intermediate
diff --git a/doc/user/group/saml_sso/troubleshooting_scim.md b/doc/user/group/saml_sso/troubleshooting_scim.md
index 5140e121bfb..1a8a719f98b 100644
--- a/doc/user/group/saml_sso/troubleshooting_scim.md
+++ b/doc/user/group/saml_sso/troubleshooting_scim.md
@@ -127,6 +127,47 @@ For example, use these values as a definitive source on why an account was provi
 details. This information can help where an account was SCIM provisioned with details that do not match
 the SCIM app configuration.
 
+## Member's email address is not linked error in SCIM log
+
+When you attempt to provision a SCIM user on GitLab.com, GitLab checks to see if
+a user with that email address already exists. You might see the following error
+when the:
+
+- User exists, but does not have a SAML identity linked.
+- User exists, has a SAML identity, **and** has a SCIM identity that is set to `active: false`.
+
+```plaintext
+The member's email address is not linked to a SAML account or has an inactive
+SCIM identity.
+```
+
+This error message is returned with the status `412`.
+
+This might prevent the affected end user from accessing their account correctly.
+
+The first workaround is:
+
+1. Have the end user [link SAML to their existing GitLab.com account](index.md#link-saml-to-your-existing-gitlabcom-account).
+1. After the user has done this, initiate a SCIM sync from your identity provider.
+If the SCIM sync completes without the same error, GitLab has
+successfully linked the SCIM identity to the existing user account, and the user
+should now be able to sign in using SAML SSO.
+
+If the error persists, the user most likely already exists, has both a SAML and
+SCIM identity, and a SCIM identity that is set to `active: false`. To resolve
+this:
+
+1. Optional. If you did not save your SCIM token when you first configured SCIM, [generate a new token](scim_setup.md#configure-gitlab). If you generate a new SCIM token, you **must** update the token in your identity provider's SCIM configuration, or SCIM will stop working.
+1. Locate your SCIM token.
+1. Use the API to [get a single SCIM provisioned user](/ee/development/internal_api/index.md#get-a-single-scim-provisioned-user).
+1. Check the returned information to make sure that:
+   - The user's identifier (`id`) and email match what your identity provider is sending.
+   - `active` is set to `false`.
+   If any of this information does not match, [contact GitLab Support](https://support.gitlab.com/).
+1. Use the API to [update the SCIM provisioned user's `active` value to `true`](/ee/development/internal_api/index.md#update-a-single-scim-provisioned-user).
+1. If the update returns a status code `204`, have the user attempt to sign in
+using SAML SSO.
+
 ## Azure Active Directory
 
 The following troubleshooting information is specifically for SCIM provisioned through Azure Active Directory.
diff --git a/doc/user/workspace/configuration.md b/doc/user/workspace/configuration.md
index a1308d04653..ae49b866bbd 100644
--- a/doc/user/workspace/configuration.md
+++ b/doc/user/workspace/configuration.md
@@ -30,12 +30,7 @@ which you can customize to meet the specific needs of each project.
   that controller accessible over a domain. For example, point `*.workspaces.example.dev`
   and `workspaces.example.dev` to the load balancer exposed by the Ingress controller.
   - [Install `gitlab-workspaces-proxy`](https://gitlab.com/gitlab-org/remote-development/gitlab-workspaces-proxy#installation-instructions).
-  - [Install the GitLab agent](../clusters/agent/install/index.md).
-- Configure [remote development settings for the GitLab agent](gitlab_agent_configuration.md).
-
-  You can use any agent defined under the root group of your project,
-  provided that remote development is properly configured for that agent.
-
+  - [Install](../clusters/agent/install/index.md) and [configure](gitlab_agent_configuration.md) the GitLab agent.
 - You must have at least the Developer role in the root group.
 - In each project you want to use this feature for, create a [devfile](index.md#devfile):
   1. On the left sidebar, select **Search or go to** and find your project.
diff --git a/doc/user/workspace/gitlab_agent_configuration.md b/doc/user/workspace/gitlab_agent_configuration.md
index d74014e9f1f..8f8ae397f5d 100644
--- a/doc/user/workspace/gitlab_agent_configuration.md
+++ b/doc/user/workspace/gitlab_agent_configuration.md
@@ -4,11 +4,16 @@ group: IDE
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# GitLab agent configuration
+# GitLab agent configuration **(PREMIUM ALL)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112397) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `remote_development_feature_flag`. Disabled by default.
+> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/391543) in GitLab 16.0.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136744) in GitLab 16.7. Feature flag `remote_development_feature_flag` removed.
 
 When you [set up a workspace](configuration.md#set-up-a-workspace),
-you must configure remote development settings for the GitLab agent.
-These settings are available in the agent configuration file under `remote_development`.
+you must configure remote development for the GitLab agent.
+The remote development settings are available in the agent
+configuration file under `remote_development`.
 
 You can use any agent defined under the root group of your project,
 provided that remote development is properly configured for that agent.
@@ -23,7 +28,7 @@ provided that remote development is properly configured for that agent.
 | [`network_policy`](#network_policy)                   | Firewall rules for workspaces                                        |
 
 NOTE:
-If any setting has an invalid value, all settings cannot be updated until you fix that value.
+If a setting has an invalid value, it's not possible to update any setting until you fix that value.
 
 ### `enabled`
 
@@ -109,12 +114,12 @@ Use this setting to define a list of IP CIDR ranges to allow as egress destinati
 
 Define egress rules when:
 
-- The GitLab instance is available on a private IP.
-- Workspace users must access a cloud resource available on a private IP.
+- The GitLab instance is on a private IP range.
+- Workspace users must access a cloud resource on a private IP range.
 
 Each element of the list defines an `allow` attribute with an optional `except` attribute.
-The `allow` attribute defines an IP CIDR range to allow traffic from.
-The `except` attribute lists IP CIDR ranges to exclude from the `allow` range.
+`allow` defines an IP range to allow traffic from.
+`except` lists IP ranges to exclude from the `allow` range.
 
 **Example configuration:**
 
@@ -132,5 +137,5 @@ remote_development:
 
 In this example, traffic from the workspace is allowed if:
 
-- The destination IP is any IP except `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`.
+- The destination IP is any range except `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16`.
 - The destination IP is `172.16.123.1/32`.