Add latest changes from gitlab-org/gitlab@master

9 files changed, 78 insertions, 90 deletions

diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 5f04326d49f..ff71ba4f94f 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -865,6 +865,7 @@ For each node running a Patroni instance on the secondary site:
    consul['configuration'] = {
      retry_join: %w[CONSUL_SECONDARY1_IP CONSUL_SECONDARY2_IP CONSUL_SECONDARY3_IP]
    }
+   consul['services'] = %w(postgresql)
 
    postgresql['md5_auth_cidr_addresses'] = [
      'PATRONI_SECONDARY1_IP/32', 'PATRONI_SECONDARY2_IP/32', 'PATRONI_SECONDARY3_IP/32', 'PATRONI_SECONDARY_PGBOUNCER/32',
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 3e3846e7fd7..69483ddf693 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -1606,7 +1606,7 @@ Configure Gitaly to sign commits made with the GitLab UI in one of two ways:
 
 ## Generate configuration using an external command
 
-> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4828) in GitLab 15.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4828) in GitLab 15.11.
 
 You can generate parts of the Gitaly configuration using an external command. You might do this:
 
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 34e72f3eb5a..36f7456f22e 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -69,7 +69,7 @@ the current status of these issues, refer to the referenced issues and epics.
 
 | Issue                                                                                 | Summary                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     | How to avoid |
 |:--------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:--------------------------------|
-| Gitaly Cluster + Geo - Issues retrying failed syncs                             | If Gitaly Cluster is used on a Geo secondary site, repositories that have failed to sync could continue to fail when Geo tries to resync them. Recovering from this state requires assistance from support to run manual steps. | No known solution prior to GitLab 15.0. In GitLab 15.0 to 15.2, enable the [`gitaly_praefect_generated_replica_paths` feature flag](#praefect-generated-replica-paths-gitlab-150-and-later). In GitLab 15.3, the feature flag is enabled by default. |
+| Gitaly Cluster + Geo - Issues retrying failed syncs                             | If Gitaly Cluster is used on a Geo secondary site, repositories that have failed to sync could continue to fail when Geo tries to resync them. Recovering from this state requires assistance from support to run manual steps. | No known solution prior to GitLab 15.0. In GitLab 15.0 to 15.2, enable the [`gitaly_praefect_generated_replica_paths` feature flag](#praefect-generated-replica-paths-gitlab-150-and-later) on your Geo primary site. In GitLab 15.3, the feature flag is enabled by default. |
 | Praefect unable to insert data into the database due to migrations not being applied after an upgrade | If the database is not kept up to date with completed migrations, then the Praefect node is unable to perform standard operation. | Make sure the Praefect database is up and running with all migrations completed (For example: `/opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml sql-migrate-status` should show a list of all applied migrations). Consider [requesting upgrade assistance](https://about.gitlab.com/support/scheduling-upgrade-assistance/) so your upgrade plan can be reviewed by support. |
 | Restoring a Gitaly Cluster node from a snapshot in a running cluster | Because the Gitaly Cluster runs with consistent state, introducing a single node that is behind results in the cluster not being able to reconcile the nodes data and other nodes data | Don't restore a single Gitaly Cluster node from a backup snapshot. If you must restore from backup:<br/><br/>1. [Shut down GitLab](../read_only_gitlab.md#shut-down-the-gitlab-ui).<br/>2. Snapshot all Gitaly Cluster nodes at the same time.<br/>3. Take a database dump of the Praefect database. |
 | Rebuilding or replacing an existing Gitaly Cluster node | There is no way to replace existing nodes in place because the Praefect database is relied on to determine the current state of each Gitaly node. Changing how Gitaly Cluster stores repositories is proposed in issue [4218](https://gitlab.com/gitlab-org/gitaly/-/issues/4218). Turning on [repository verification](praefect.md#repository-verification) is proposed in issue [4429](https://gitlab.com/gitlab-org/gitaly/-/issues/4429) so Praefect can detect that data is missing and needs to replicated to a new Gitaly node. | No known solution at this time. |
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 5c258d73fdb..16e758d5355 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -11,7 +11,7 @@ GitLab provides Rake tasks for general maintenance.
 ## Gather GitLab and system information
 
 This command gathers information about your GitLab installation and the system it runs on.
-These may be useful when asking for help or reporting issues.
+These may be useful when asking for help or reporting issues. In a multi-node environment, run this command on nodes running GitLab Rails to avoid PostgreSQL socket errors.
 
 **Omnibus Installation**
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index f936f3096ef..986779fce52 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -270,6 +270,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="queryissuesiid"></a>`iid` | [`String`](#string) | IID of the issue. For example, "1". |
 | <a id="queryissuesiids"></a>`iids` | [`[String!]`](#string) | List of IIDs of issues. For example, `["1", "2"]`. |
 | <a id="queryissuesin"></a>`in` | [`[IssuableSearchableField!]`](#issuablesearchablefield) | Specify the fields to perform the search in. Defaults to `[TITLE, DESCRIPTION]`. Requires the `search` argument.'. |
+| <a id="queryissuesincludearchived"></a>`includeArchived` | [`Boolean`](#boolean) | Whether to include issues from archived projects. Defaults to `false`. |
 | <a id="queryissuesincludesubepics"></a>`includeSubepics` | [`Boolean`](#boolean) | Whether to include subepics when filtering issues by epicId. |
 | <a id="queryissuesiterationid"></a>`iterationId` | [`[ID]`](#id) | List of iteration Global IDs applied to the issue. |
 | <a id="queryissuesiterationwildcardid"></a>`iterationWildcardId` | [`IterationWildcardId`](#iterationwildcardid) | Filter by iteration ID wildcard. |
diff --git a/doc/development/database/batched_background_migrations.md b/doc/development/database/batched_background_migrations.md
index 67dccd99a6c..57d3aac2cbc 100644
--- a/doc/development/database/batched_background_migrations.md
+++ b/doc/development/database/batched_background_migrations.md
@@ -768,7 +768,7 @@ To do that, you need to:
 
 #### 1. Find the batch `start_id` and `end_id`
 
-You should be able to find those in [Kibana][#viewing-failure-error-logs].
+You should be able to find those in [Kibana](#viewing-failure-error-logs).
 
 #### 2. Create a regular migration
 
@@ -809,7 +809,7 @@ index b8d1d21a0d2d2a23d9e8c8a0a17db98ed1ed40b7..912e20659a6919f771045178c6682856
 +++ b/lib/gitlab/database/migration_helpers/restrict_gitlab_schema.rb
 @@ -55,7 +55,7 @@ def unmatched_schemas
          end
- 
+
          def allowed_schemas_for_connection
 -          Gitlab::Database.gitlab_schemas_for_connection(connection)
 +          Gitlab::Database.gitlab_schemas_for_connection(connection) << :gitlab_ci
@@ -828,7 +828,7 @@ index 4ae3622479f0800c0553959e132143ec9051898e..d556ec7f55adae9d46a56665ce02de78
 @@ -79,7 +79,7 @@ def restrict_to_dml_only(parsed)
              tables = self.dml_tables(parsed)
              schemas = self.dml_schemas(tables)
- 
+
 -            if (schemas - self.allowed_gitlab_schemas).any?
 +            if (schemas - (self.allowed_gitlab_schemas << :gitlab_ci)).any?
                raise DMLAccessDeniedError, \
diff --git a/doc/development/product_qualified_lead_guide/index.md b/doc/development/product_qualified_lead_guide/index.md
index 41237dcdff4..fb8ec478840 100644
--- a/doc/development/product_qualified_lead_guide/index.md
+++ b/doc/development/product_qualified_lead_guide/index.md
@@ -117,7 +117,7 @@ expect(wrapper.findComponent(HandRaiseLeadButton).exists()).toBe(true);
 The flow of a PQL lead is as follows:
 
 1. A user triggers a [`HandRaiseLeadButton` component](#embed-a-hand-raise-lead-form) on `gitlab.com`.
-1. The `HandRaiseLeadButton` submits any information to the following API endpoint: `/-/trials/create_hand_raise_lead`.
+1. The `HandRaiseLeadButton` submits any information to the following API endpoint: `/-/subscriptions/hand_raise_leads`.
 1. That endpoint reposts the form to the CustomersDot `trials/create_hand_raise_lead` endpoint.
 1. CustomersDot records the form data to the `leads` table and posts the form to [Workato](https://about.gitlab.com/handbook/marketing/marketing-operations/workato/).
 1. Workato sends the form to Marketo.
@@ -170,7 +170,7 @@ sequenceDiagram
 ```mermaid
 sequenceDiagram
     HandRaiseForm Vue Component->>TrialsController#create_hand_raise_lead: GitLab.com frontend sends [lead] to backend
-    TrialsController#create_hand_raise_lead->>CreateHandRaiseLeadService: [lead]
+    Subscriptions::HandRaiseLeadsController#create->>CreateHandRaiseLeadService: [lead]
     CreateHandRaiseLeadService->>SubscriptionPortalClient: [lead]
     SubscriptionPortalClient->>CustomersDot|TrialsController#create_hand_raise_lead: GitLab.com sends [lead] to CustomersDot
 ```
diff --git a/doc/update/index.md b/doc/update/index.md
index 07bd153907a..762bb6c8765 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -289,6 +289,11 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
   You can find repositories with invalid metadata records prior in GitLab 15.0 and later by searching for the log records outputted by the verifier. [Read more about repository verification, and to see an example log entry](../administration/gitaly/praefect.md#repository-verification).
 - Praefect configuration changes significantly in Omnibus GitLab 16.0. You can begin migrating to the new structure in Omnibus GitLab 15.9 while backwards compatibility is
   maintained in the lead up to Omnibus GitLab 16.0. [Read more about this change](#praefect-omnibus-gitlab-configuration-structure-change).
+- For **self-compiled (source) installations**, with the addition of `gitlab-sshd` the Kerberos headers are needed to build GitLab Shell.
+
+  ```shell
+  sudo apt install libkrb5-dev
+  ```
 
 ### 15.8.2
 
@@ -733,6 +738,36 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706)
 - The `FF_GITLAB_REGISTRY_HELPER_IMAGE` [feature flag](../administration/feature_flags.md#enable-or-disable-the-feature) is removed and helper images are always pulled from GitLab Registry.
 - The `AES256-GCM-SHA384` SSL cipher is no longer allowed by NGINX.
   See how you can [add the cipher back](https://docs.gitlab.com/omnibus/update/gitlab_15_changes.html#aes256-gcm-sha384-ssl-cipher-no-longer-allowed-by-default-by-nginx) to the allow list.
+- Support for more than one database has been added to GitLab. For **self-compiled (source) installations**,
+  `config/database.yml` must include a database name in the database configuration.
+  The `main: database` must be first. If an invalid or deprecated syntax is used, an error is generated
+  during application start:
+
+  ```plaintext
+  ERROR: This installation of GitLab uses unsupported 'config/database.yml'.
+  The main: database needs to be defined as a first configuration item instead of primary. (RuntimeError)
+  ```
+
+  Previously, the `config/database.yml` file looked like the following:
+
+  ```yaml
+  production:
+    adapter: postgresql
+    encoding: unicode
+    database: gitlabhq_production
+    ...
+  ```
+
+  Starting with GitLab 15.0, it must define a `main` database first:
+
+  ```yaml
+  production:
+    main:
+      adapter: postgresql
+      encoding: unicode
+      database: gitlabhq_production
+      ...
+  ```
 
 ### 14.10.0
 
@@ -925,6 +960,19 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
 
   [There is a workaround to complete the data change and the upgrade manually](package/index.md#mixlibshelloutcommandtimeout-rails_migrationgitlab-rails--command-timed-out-after-3600s)
 
+- As part of [enabling real-time issue assignees](https://gitlab.com/gitlab-org/gitlab/-/issues/330117), Action Cable is now enabled by default.
+  For **self-compiled (source) installations**, `config/cable.yml` is required to be present.
+
+  Configure this by running:
+
+  ```shell
+  cd /home/git/gitlab
+  sudo -u git -H cp config/cable.yml.example config/cable.yml
+
+  # Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
+  sudo -u git -H editor config/cable.yml
+  ```
+
 ### 14.4.4
 
 - For [zero-downtime upgrades](zero_downtime.md) on a GitLab cluster with separate Web and API nodes, you must enable the `paginated_tree_graphql_query` [feature flag](../administration/feature_flags.md#enable-or-disable-the-feature) _before_ upgrading GitLab Web nodes to 14.4.
@@ -1390,12 +1438,23 @@ all servers must first be upgraded to 13.1.Z before upgrading to 13.2.0 or later
 
 #### Custom Rack Attack initializers
 
-From GitLab 13.0.1, custom Rack Attack initializers (`config/initializers/rack_attack.rb`) are replaced with initializers
-supplied with GitLab during upgrades. We recommend you use these GitLab-supplied initializers.
+From GitLab 13.1, custom Rack Attack initializers (`config/initializers/rack_attack.rb`) are replaced with initializers
+supplied with GitLab during upgrades. You should use these GitLab-supplied initializers.
 
 If you persist your own Rack Attack initializers between upgrades, you might
 [get `500` errors](https://gitlab.com/gitlab-org/gitlab/-/issues/334681) when [upgrading to GitLab 14.0 and later](#1400).
 
+For **self-compiled (source) installations**, the Rack Attack initializer on GitLab
+was renamed from [`config/initializers/rack_attack_new.rb` to `config/initializers/rack_attack.rb`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33072).
+The rename was part of [deprecating Rack Attack throttles on Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4750).
+
+If `rack_attack.rb` has been created on your installation, consider creating a backup before updating:
+
+```shell
+cd /home/git/gitlab
+cp config/initializers/rack_attack.rb config/initializers/rack_attack_backup.rb
+```
+
 ### 12.10.0
 
 - The final patch release (12.10.14)
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 400c5012e03..b4dae3247ac 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -334,8 +334,8 @@ sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workh
 ```
 
 NOTE:
-If you get any errors concerning Rack attack, see the [13.0](#1301) specific
-upgrade instructions.
+If you get any errors concerning Rack attack, see the [13.1](index.md#custom-rack-attack-initializers)
+specific changes.
 
 ### 13. Update Gitaly
 
@@ -404,85 +404,12 @@ If all items are green, then congratulations, the upgrade is complete!
 This is an optional step. If you [installed the product documentation](../install/installation.md#install-the-product-documentation),
 see how to [upgrade to a later version](../administration/docs_self_host.md#upgrade-the-product-documentation-to-a-later-version).
 
-## Version specific upgrading instructions
+## Version specific changes
 
-This section contains upgrading instructions for specific versions. When
-present, first follow the upgrading guidelines for all versions. If the version
-you are upgrading to is not listed here, then no additional steps are required.
-
-<!--
-Example:
-
-### 11.8.0
-
-Additional instructions here.
--->
-
-### 15.9.0
-
-With the addition of `gitlab-sshd` the Kerberos headers are needed to build GitLab Shell.
-
-```shell
-sudo apt install libkrb5-dev
-```
-
-### 15.0.0
-
-Support for more than one database has been added to GitLab. [As part of this](https://gitlab.com/gitlab-org/gitlab/-/issues/338182),
-`config/database.yml` must include a database name in the database configuration.
-The `main: database` must be first. If an invalid or deprecated syntax is used, an error is generated
-during application start:
-
-```plaintext
-ERROR: This installation of GitLab uses unsupported 'config/database.yml'.
-The main: database needs to be defined as a first configuration item instead of primary. (RuntimeError)
-```
-
-Previously, the `config/database.yml` file looked like the following:
-
-```yaml
-production:
-  adapter: postgresql
-  encoding: unicode
-  database: gitlabhq_production
-  ...
-```
-
-Starting with GitLab 15.0, it must define a `main` database first:
-
-```yaml
-production:
-  main:
-    adapter: postgresql
-    encoding: unicode
-    database: gitlabhq_production
-    ...
-```
-
-### 14.5.0
-
-As part of [enabling real-time issue assignees](https://gitlab.com/gitlab-org/gitlab/-/issues/330117), Action Cable is now enabled by default, and requires `config/cable.yml` to be present.
-You can configure this by running:
-
-```shell
-cd /home/git/gitlab
-
-sudo -u git -H cp config/cable.yml.example config/cable.yml
-
-# Change the Redis socket path if you are not using the default Debian / Ubuntu configuration
-sudo -u git -H editor config/cable.yml
-```
-
-### 13.0.1
-
-As part of [deprecating Rack Attack throttles on Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4750), the Rack Attack initializer on GitLab
-was renamed from [`config/initializers/rack_attack_new.rb` to `config/initializers/rack_attack.rb`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33072).
-If this file exists on your installation, consider creating a backup before updating:
-
-```shell
-cd /home/git/gitlab
-cp config/initializers/rack_attack.rb ~/config/initializers/rack_attack_backup.rb
-```
+Upgrading versions might need some manual intervention. For more information,
+[check the version you are upgrading to](index.md#version-specific-upgrading-instructions)
+for additional steps required for all GitLab installations, and for
+steps that apply to self-compiled (source) installations.
 
 ## Troubleshooting