Add latest changes from gitlab-org/gitlab@master

Author: GitLab Bot

.gitlab/issue_templates/Bug.md

@@ -42,7 +42,10 @@ will also determine whether the bug is fixed in a more recent version. -->
 <!-- If you are reporting a bug on GitLab.com, uncomment below -->
 
 <!-- This bug happens on GitLab.com -->
+
+<!-- and uncomment below if you have /label privileges -->
 <!-- /label ~"reproduced on GitLab.com" -->
+<!-- or follow up with an issue comment of `@gitlab-bot label ~"reproduced on GitLab.com"` if you do not -->
 
 #### Results of GitLab environment info
 
@@ -86,3 +89,5 @@ will also determine whether the bug is fixed in a more recent version. -->
 <!-- If you can, link to the line of code that might be responsible for the problem. -->
 
 /label ~"type::bug"
+<!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->
+

app/graphql/resolvers/ci/project_pipeline_analytics_resolver.rb

@@ -13,6 +13,16 @@ class ProjectPipelineAnalyticsResolver < BaseResolver
 
       alias_method :project, :object
 
+      argument :source, Types::PipelineCiSourcesEnum,
+        required: false,
+        description: 'Source of the pipeline.',
+        alpha: { milestone: '17.5' }
+
+      argument :ref, GraphQL::Types::String,
+        required: false,
+        description: 'Branch that triggered the pipeline.',
+        alpha: { milestone: '17.5' }
+
       argument :from_time, Types::TimeType,
         required: false,
         description: 'Start of the requested time frame. Defaults to the pipelines started in the past week.',
@@ -23,13 +33,15 @@ class ProjectPipelineAnalyticsResolver < BaseResolver
         description: 'End of the requested time frame. Defaults to pipelines started before the current date.',
         alpha: { milestone: '17.5' }
 
-      def resolve(lookahead:, from_time: nil, to_time: nil)
+      def resolve(lookahead:, source: nil, ref: nil, from_time: nil, to_time: nil)
         result = legacy_fields(lookahead)
 
         if any_field_selected?(lookahead, :aggregate)
           response =
             ::Ci::CollectPipelineAnalyticsService.new(
-              current_user: context[:current_user], project: project, from_time: from_time, to_time: to_time,
+              current_user: context[:current_user], project: project,
+              source: source, ref: ref,
+              from_time: from_time, to_time: to_time,
               status_groups: selected_status_groups(lookahead)
             ).execute
 

app/graphql/types/pipeline_ci_sources_enum.rb

@@ -0,0 +1,15 @@
+# frozen_string_literal: true
+
+module Types
+  class PipelineCiSourcesEnum < BaseEnum # rubocop:disable Gitlab/BoundedContexts -- Disabling because it's a custom enum
+    graphql_name 'PipelineCiSources'
+    description 'Pipeline CI sources'
+
+    Enums::Ci::Pipeline.ci_sources.each_key do |source|
+      article = %w[a e i o u].include?(source.to_s[0].downcase) ? 'an' : 'a'
+      desc_source = source.to_s.include?('api') ? 'API' : source
+      description = "Pipeline created by #{article} #{desc_source.to_s.tr('_', ' ').delete_suffix(' event')} event"
+      value source.to_s.upcase, value: source, description: description
+    end
+  end
+end

app/helpers/preferences_helper.rb

@@ -27,8 +27,14 @@ def dashboard_choices
 
   # Maps `dashboard` values to more user-friendly option text
   def localized_dashboard_choices
+    projects = if Feature.enabled?(:your_work_projects_vue, current_user)
+                 _("Your Contributed Projects (default)")
+               else
+                 _("Your Projects (default)")
+               end
+
     {
-      projects: _("Your Projects (default)"),
+      projects: projects,
       stars: _("Starred Projects"),
       your_activity: _("Your Activity"),
       project_activity: _("Your Projects' Activity"),

app/services/ci/collect_pipeline_analytics_service.rb

@@ -6,10 +6,12 @@ class CollectPipelineAnalyticsService
     STATUS_GROUPS = STATUS_GROUP_TO_STATUSES.keys.freeze
     STATUS_TO_STATUS_GROUP = STATUS_GROUP_TO_STATUSES.flat_map { |k, v| v.product([k]) }.to_h
 
-    def initialize(current_user:, project:, from_time:, to_time:, status_groups: [:all])
+    def initialize(current_user:, project:, from_time:, to_time:, source: nil, ref: nil, status_groups: [:all])
       @current_user = current_user
       @project = project
       @status_groups = status_groups
+      @source = source
+      @ref = ref
       @from_time = from_time || 1.week.ago.utc
       @to_time = to_time || Time.now.utc
     end
@@ -45,7 +47,14 @@ def clickhouse_model
 
     def calculate_aggregate
       result = @status_groups.index_with(0)
-      query = clickhouse_model.for_project(@project).within_dates(@from_time, @to_time)
+
+      query = clickhouse_model
+        .for_project(@project)
+        .within_dates(@from_time, @to_time)
+
+      query = query.for_source(@source) if @source
+      query = query.for_ref(@ref) if @ref
+
       if @status_groups.include?(:all)
         all_query = query.select(query.count_pipelines_function.as('all'))
         result[:all] = ::ClickHouse::Client.select(all_query.to_sql, :main).first['all']

config/feature_flags/gitlab_com_derisk/partition_ci_build_trace_metadata.yml

@@ -0,0 +1,9 @@
+---
+name: partition_ci_build_trace_metadata
+feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/469056
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/168756
+rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/481800
+milestone: '17.5'
+group: group::ci platform
+type: gitlab_com_derisk
+default_enabled: false

config/initializers/postgres_partitioning.rb

@@ -102,4 +102,22 @@
     }
   ]
 )
+
+Gitlab::Database::Partitioning.register_tables(
+  [
+    {
+      limit_connection_names: %i[ci],
+      table_name: 'p_ci_build_trace_metadata',
+      partitioned_column: :partition_id,
+      strategy: :ci_sliding_list,
+      next_partition_if: ->(latest_partition) {
+                           ::Feature.enabled?(:partition_ci_build_trace_metadata, :instance) &&
+                            latest_partition &&
+                            [100, 101].include?(latest_partition.values.max)
+                         },
+      detach_partition_if: proc { false }
+    }
+  ]
+)
+
 Gitlab::Database::Partitioning.sync_partitions_ignore_db_error

doc/administration/backup_restore/backup_gitlab.md

@@ -388,7 +388,7 @@ DECOMPRESS_CMD=tee gitlab-backup restore
 ##### Parallel compression with `pigz`
 
 WARNING:
-While we support using `COMPRESS_CMD` and `DECOMPRESS_CMD` to override the default Gzip compression library, we currently only test the default Gzip library with default options on a routine basis. You are responsible for testing and validating the viability of your backups. We strongly recommend this as best practice in general for backups, whether overriding the compression command or not. If you encounter issues with another compression library, you should revert back to the default. Troubleshooting and fixing errors with alternative libraries are a lower priority for GitLab.
+While we support using `COMPRESS_CMD` and `DECOMPRESS_CMD` to override the default Gzip compression library, we only test the default Gzip library with default options on a routine basis. You are responsible for testing and validating the viability of your backups. We strongly recommend this as best practice in general for backups, whether overriding the compression command or not. If you encounter issues with another compression library, you should revert back to the default. Troubleshooting and fixing errors with alternative libraries are a lower priority for GitLab.
 
 NOTE:
 `pigz` is not included in the GitLab Linux package. You must install it yourself.
@@ -408,7 +408,7 @@ DECOMPRESS_CMD="pigz --decompress --stdout" sudo gitlab-backup restore
 ##### Parallel compression with `zstd`
 
 WARNING:
-While we support using `COMPRESS_CMD` and `DECOMPRESS_CMD` to override the default Gzip compression library, we currently only test the default Gzip library with default options on a routine basis. You are responsible for testing and validating the viability of your backups. We strongly recommend this as best practice in general for backups, whether overriding the compression command or not. If you encounter issues with another compression library, you should revert back to the default. Troubleshooting and fixing errors with alternative libraries are a lower priority for GitLab.
+While we support using `COMPRESS_CMD` and `DECOMPRESS_CMD` to override the default Gzip compression library, we only test the default Gzip library with default options on a routine basis. You are responsible for testing and validating the viability of your backups. We strongly recommend this as best practice in general for backups, whether overriding the compression command or not. If you encounter issues with another compression library, you should revert back to the default. Troubleshooting and fixing errors with alternative libraries are a lower priority for GitLab.
 
 NOTE:
 `zstd` is not included in the GitLab Linux package. You must install it yourself.

doc/administration/backup_restore/migrate_to_new_server.md

@@ -92,8 +92,8 @@ To prepare the new server:
    1. On the left sidebar, select **Monitoring > Background jobs**.
    1. Under the Sidekiq dashboard, select **Cron** tab and then
       **Disable All**.
-1. Wait for the currently running CI/CD jobs to finish, or accept that jobs that have not completed may be lost.
-   To view jobs currently running, on the left sidebar, select **Overviews > Jobs**,
+1. Wait for the running CI/CD jobs to finish, or accept that jobs that have not completed may be lost.
+   To view jobs running, on the left sidebar, select **Overviews > Jobs**,
    and then select **Running**.
 1. Wait for Sidekiq jobs to finish:
    1. On the left sidebar, select **Monitoring > Background jobs**.

doc/administration/backup_restore/troubleshooting_backup_gitlab.md

@@ -375,7 +375,7 @@ Truncate the filenames in the `uploads` table:
 
       Where:
 
-      - `current_filename`: a filename that is currently more than 246 characters long.
+      - `current_filename`: a filename that is more than 246 characters long.
       - `new_filename`: a filename that has been truncated to 246 characters maximum.
       - `new_path`: new path considering the `new_filename` (truncated).
 

doc/administration/dedicated/configure_instance.md

@@ -78,7 +78,7 @@ You can use the configuration change log to track the changes made to your GitLa
 Each configuration change has a status:
 
 - Initiated: Configuration change is made in Switchboard, but not yet deployed to the instance.
-- In progress: Configuration change is currently being deployed to the instance.
+- In progress: Configuration change is actively being deployed to the instance.
 - Complete: Configuration change has been deployed to the instance.
 - Delayed: Initial job to deploy a change has failed and the change has not yet been assigned to a new job.
 

doc/administration/geo/disaster_recovery/index.md

@@ -19,8 +19,8 @@ causes downtime.
 
 ## Promoting a **secondary** Geo site in single-secondary configurations
 
-We don't currently provide an automated way to promote a Geo replica and do a
-failover, but you can do it manually if you have `root` access to the machine.
+While you can't automatically promote a Geo replica and do a failover,
+you can promote it manually if you have `root` access to the machine.
 
 This process promotes a **secondary** Geo site to a **primary** site. To regain
 geographic redundancy as quickly as possible, you should add a new **secondary** site

doc/administration/geo/replication/faq.md

@@ -48,7 +48,7 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
 
 ## What data is replicated to a **secondary** site?
 
-We currently replicate the whole rails database, project repositories, LFS objects, generated
+We replicate the whole rails database, project repositories, LFS objects, generated
 attachments, avatars and more. This means information such as user accounts,
 issues, merge requests, groups, and project data are available for
 query.

doc/administration/geo/replication/object_storage.md

@@ -69,7 +69,7 @@ configure the **secondary** in a few ways:
 - Use a separate object store and enable the **Allow this secondary node to replicate
   content on Object Storage** setting.
 
-GitLab does not currently support the case where both:
+GitLab does not support the case where both:
 
 - The **primary** site uses local storage.
 - A **secondary** site uses object storage.

doc/administration/geo/replication/security_review.md

@@ -272,7 +272,7 @@ from [owasp.org](https://owasp.org/).
 
 ### What user authorization requirements have been defined?
 
-- **Secondary** sites must only be able to *read* data. They are not currently able to mutate data on the **primary** site.
+- **Secondary** sites must only be able to *read* data. They cannot mutate data on the **primary** site.
 
 ### What session management requirements have been defined?
 

doc/administration/geo/replication/troubleshooting/synchronization.md

@@ -301,7 +301,7 @@ project.replicator.sync
 
 The following script:
 
-- Loops over all currently failed repositories.
+- Loops over all failed repositories.
 - Displays the project details and the reasons for the last failure.
 - Attempts to resync the repository.
 - Reports back if a failure occurs, and why.

doc/administration/geo/secondary_proxy/index.md

@@ -118,7 +118,7 @@ distributes traffic to your Geo sites using a location-aware URL.
 ### Configure each site to use the same external URL
 
 After you have set up routing from a single URL to all of your Geo sites, follow
-the following steps if your sites currently use different URLs:
+the following steps if your sites use different URLs:
 
 1. On each GitLab site, SSH into **each** node running Rails (Puma, Sidekiq, Log-Cursor)
    and set the `external_url` to that of the single URL:
@@ -153,7 +153,7 @@ GitLab does not support multiple external URLs, see [issue 21319](https://gitlab
 
 ### Configure a secondary Geo site to a different external URL than the primary site
 
-If your secondary site currently uses the same external URL as the primary site:
+If your secondary site uses the same external URL as the primary site:
 
 1. On the secondary site, SSH into **each** node running Rails (Puma, Sidekiq, Log-Cursor)
    and set the `external_url` to the desired URL for the secondary site:
@@ -197,7 +197,7 @@ Most HTTP traffic sent to a secondary Geo site is proxied to the primary Geo sit
 secondary Geo sites are able to support write requests, and avoid read-after-write problems. Certain
 **read** requests are handled locally by secondary sites for improved latency and bandwidth nearby.
 
-The following table details the components currently tested through the Geo secondary site Workhorse proxy.
+The following table details the components tested through the Geo secondary site Workhorse proxy.
 It does not cover all data types.
 
 In this context, accelerated reads refer to read requests served from the secondary site, provided that the data is up to date for the component on the secondary site. If the data on the secondary site is determined to be out of date, the request is forwarded to the primary site. Read requests for components not listed in the table below are always automatically forwarded to the primary site.

doc/administration/geo_sites.md

@@ -28,7 +28,7 @@ All Geo sites have the following settings:
 | Name    | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. |
 | URL     | The instance's user-facing URL. |
 
-The site you're currently browsing is indicated with a blue `Current` label, and
+The site you're browsing is indicated with a blue `Current` label, and
 the **primary** node is listed first as `Primary site`.
 
 ## Secondary site settings

doc/administration/operations/ssh_certificates.md

@@ -153,14 +153,15 @@ Consider the balance between the number of keys for typical users (especially if
 
 Users can still bypass SSH certificate authentication by manually
 uploading an SSH public key to their profile, relying on the
-`~/.ssh/authorized_keys` fallback to authenticate it. There's
-currently no feature to prevent this,
-[but there's an open request for adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
-
-Such a restriction can currently be hacked in by, for example, providing a
-custom `AuthorizedKeysCommand` which checks if the discovered key-ID
-returned from `gitlab-shell-authorized-keys-check` is a deploy key or
-not (all non-deploy keys should be refused).
+`~/.ssh/authorized_keys` fallback to authenticate it.
+
+There's an [open issue](https://gitlab.com/gitlab-org/gitlab/-/issues/23260)
+to add a setting that prevents users from uploading SSH keys that are not deploy keys.
+
+You can build a check to enforce this restriction yourself.
+For example, provide a custom `AuthorizedKeysCommand` which checks
+if the discovered key-ID returned from `gitlab-shell-authorized-keys-check`
+is a deploy key or not (all non-deploy keys should be refused).
 
 ## Disabling the global warning about users lacking SSH keys
 

doc/administration/package_information/supported_os.md

@@ -17,7 +17,7 @@ avoid confusion, the official policy is that at any point of time, all the
 operating systems supported by GitLab are listed in the
 [installation page](https://about.gitlab.com/install/).
 
-The following lists the currently supported OSs and their possible EOL dates.
+The following lists the supported OSs and their possible EOL dates.
 
 NOTE:
 `amd64` and `x86_64` refer to the same 64-bit architecture.

doc/administration/postgresql/upgrading_os.md

@@ -240,8 +240,6 @@ different types of indexes were handled, see the blog post about
 
 To see what version of `glibc` is used, run `ldd --version`.
 
-You can compare the behavior of `glibc` on your servers [using shell commands](../geo/replication/troubleshooting/common.md#check-os-locale-data-compatibility).
-
 The following table shows the `glibc` versions shipped for different operating systems:
 
 | Operating system    | `glibc` version |

doc/administration/reference_architectures/index.md

@@ -410,7 +410,7 @@ architectures are designed to have enough memory in most cases to avoid the need
 [Praefect requires its own database server](../gitaly/praefect.md#postgresql) and
 a third-party PostgreSQL database solution to achieve full HA.
 
-We hope to offer a built-in solution for these restrictions in the future. In the meantime, you can set up a 
+We hope to offer a built-in solution for these restrictions in the future. In the meantime, you can set up a
 non-HA PostgreSQL server using the Linux package as the specifications reflect. See the following issues for more information:
 
 - [`omnibus-gitlab#7292`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
@@ -812,7 +812,7 @@ The Reference Architectures have been designed to have elasticity to accommodate
 The following components can impact others when they have been significantly scaled:
 
 - Puma and Sidekiq - Notable scale ups of either Puma or Sidekiq workers will result in higher concurrent connections to the internal load balancer, PostgreSQL (via PgBouncer if present), Gitaly (via Praefect if present) and Redis respectively.
-  - Redis is primarily single threaded and in some cases may need to be split up into different instances (Cache / Persistent) if the increased throughput causes CPU exhaustion if a combined cluster is currently being used.
+  - Redis is primarily single-threaded. In some cases, you may need to split Redis into separate instances (for example, cache and persistent) if the increased throughput causes CPU exhaustion in a combined cluster.
   - PgBouncer is also single threaded but a scale out might result in a new pool being added that in turn might increase the total connections to Postgres. It's strongly recommended to only do this if you have experience in managing Postgres connections and to seek assistance if in doubt.
 - Gitaly Cluster / PostgreSQL - A notable scale out of additional nodes can have a detrimental effect on the HA system and performance due to increased replication calls to the primary node.