Add latest changes from gitlab-org/gitlab@master

.rubocop.yml

@@ -69,6 +69,11 @@ Rails:
     - 'tooling/danger/**/*'
     - 'rubocop/**/*'
 
+Rails/Date:
+  Exclude:
+    # See https://gitlab.com/gitlab-org/gitlab/-/issues/502580
+    - danger/database/Dangerfile
+
 RSpec:
   Language:
     Includes:

.rubocop_todo/lint/unused_method_argument.yml

@@ -370,7 +370,6 @@ Lint/UnusedMethodArgument:
     - 'lib/gitlab/database/each_database.rb'
     - 'lib/gitlab/database/load_balancing/connection_proxy.rb'
     - 'lib/gitlab/database/load_balancing/primary_host.rb'
-    - 'lib/gitlab/database/load_balancing/session.rb'
     - 'lib/gitlab/database/lock_writes_manager.rb'
     - 'lib/gitlab/database/migrations/instrumentation.rb'
     - 'lib/gitlab/database/migrations/lock_retries_helpers.rb'

.rubocop_todo/style/if_unless_modifier.yml

@@ -224,7 +224,6 @@ Style/IfUnlessModifier:
     - 'config/initializers/validate_database_config.rb'
     - 'config/initializers_before_autoloader/002_sidekiq.rb'
     - 'config/routes.rb'
-    - 'danger/database/Dangerfile'
     - 'ee/app/controllers/admin/emails_controller.rb'
     - 'ee/app/controllers/admin/geo/application_controller.rb'
     - 'ee/app/controllers/admin/geo/settings_controller.rb'

.rubocop_todo/style/mutable_constant.yml

@@ -11,7 +11,6 @@ Style/MutableConstant:
     - 'app/services/packages/maven/metadata/append_package_file_service.rb'
     - 'app/workers/concerns/worker_context.rb'
     - 'danger/architecture/Dangerfile'
-    - 'danger/database/Dangerfile'
     - 'ee/app/services/elastic/indexing_control_service.rb'
     - 'ee/app/services/security/ingestion/tasks/ingest_vulnerability_statistics.rb'
     - 'ee/app/services/vulnerabilities/statistics/adjustment_service.rb'

.rubocop_todo/style/redundant_self.yml

@@ -201,10 +201,6 @@ Style/RedundantSelf:
     - 'ee/lib/ee/gitlab/auth/ldap/sync/proxy.rb'
     - 'ee/lib/ee/gitlab/auth/ldap/sync/users.rb'
     - 'ee/lib/ee/gitlab/background_migration/delete_invalid_epic_issues.rb'
-    - 'ee/lib/elastic/latest/commit_config.rb'
-    - 'ee/lib/elastic/latest/issue_config.rb'
-    - 'ee/lib/elastic/latest/note_config.rb'
-    - 'ee/lib/elastic/migration.rb'
     - 'ee/lib/gem_extensions/elasticsearch/model/indexing/instance_methods.rb'
     - 'ee/lib/gitlab/analytics/cycle_analytics/summary/base_time.rb'
     - 'ee/lib/gitlab/auth/group_saml/response_check.rb'

GITLAB_KAS_VERSION

@@ -1 +1 @@
-fb36514b67173b5a16a386256a85203a0d14a76c
+ecf7544d81ceb3572d7b9afffb74c7389659caaa

danger/database/Dangerfile

@@ -2,7 +2,7 @@
 
 SCHEMA_NOT_UPDATED_MESSAGE_SHORT = "New %<migrations>s added but %<schema>s wasn't updated"
 
-SCHEMA_NOT_UPDATED_MESSAGE_FULL = <<~MSG
+SCHEMA_NOT_UPDATED_MESSAGE_FULL = <<~MSG.freeze
 **#{SCHEMA_NOT_UPDATED_MESSAGE_SHORT}**
 
 Usually, when adding new %<migrations>s, %<schema>s should be
@@ -25,7 +25,7 @@ DB_FILES_MESSAGE = <<~MSG
 The following files require a review from the Database team:
 MSG
 
-DB_REMOVE_MESSAGE = <<~MSG
+DB_REMOVE_MESSAGE = <<~MSG.freeze
 If you no longer require a database review, you can remove this suggestion
 by removing the ~database label and re-running the [`danger-review` job](#{ENV['CI_JOB_URL']}).
 MSG
@@ -91,9 +91,7 @@ if helper.mr_labels.include?('database') || database.changes.any?
     markdown(DB_REMOVE_MESSAGE)
   end
 
-  unless helper.has_scoped_label_with_scope?("database")
-    helper.labels_to_add << 'database::review pending'
-  end
+  helper.labels_to_add << 'database::review pending' unless helper.has_scoped_label_with_scope?("database")
 end
 
 cutoff = Date.today - 21 # Three weeks ago

db/docs/p_ci_build_trace_metadata.yml

@@ -8,4 +8,13 @@ description: Routing table for ci_build_trace_metadata
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/162310
 milestone: '14.2'
 gitlab_schema: gitlab_ci
-sharding_key_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/458479
+desired_sharding_key:
+  project_id:
+    references: projects
+    backfill_via:
+      parent:
+        foreign_key: build_id
+        table: p_ci_builds
+        sharding_key: project_id
+        belongs_to: build
+        foreign_key_name: fk_rails_aebc78111f_p

doc/administration/operations/rails_console.md

@@ -448,7 +448,7 @@ We also see that the save operation triggered some other action -- in this case
 a background job to deliver an email notification. This is an example of an
 [Active Record callback](https://guides.rubyonrails.org/active_record_callbacks.html)
 -- code which is designated to run in response to events in the Active Record
-object life cycle. This is also why using the Rails console is preferred when
+object lifecycle. This is also why using the Rails console is preferred when
 direct changes to data is necessary as changes made via direct database queries
 do not trigger these callbacks.
 

doc/development/api_graphql_styleguide.md

@@ -1233,7 +1233,7 @@ end
 
 While you can use the same resolver class in two different places,
 such as in two different fields where the same object is exposed,
-you should never re-use resolver objects directly. Resolvers have a complex life-cycle, with
+you should never re-use resolver objects directly. Resolvers have a complex lifecycle, with
 authorization, readiness and resolution orchestrated by the framework, and at
 each stage [lazy values](#laziness) can be returned to take advantage of batching
 opportunities. Never instantiate a resolver or a mutation in application code.

doc/development/application_slis/index.md

@@ -71,7 +71,7 @@ Gitlab::Metrics::Sli::Apdex.initialize_sli(:received_email, [
 ```
 
 Metrics must be initialized before they get scraped for the first time.
-This currently happens during the `on_master_start` [life-cycle event](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/cluster/lifecycle_events.rb).
+This currently happens during the `on_master_start` [lifecycle event](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/cluster/lifecycle_events.rb).
 Since this delays application readiness until metrics initialization returns, make sure the overhead
 this adds is understood and acceptable.
 

doc/development/database/insert_into_tables_in_batches.md

@@ -119,7 +119,7 @@ MyModel.bulk_insert!(records, skip_duplicates: true)
 ### Requirements for safe bulk insertions
 
 Large parts of ActiveRecord's persistence API are built around the notion of callbacks. Many
-of these callbacks fire in response to model life cycle events such as `save` or `create`.
+of these callbacks fire in response to model lifecycle events such as `save` or `create`.
 These callbacks cannot be used with bulk insertions, since they are meant to be called for
 every instance that is saved or created. Since these events do not fire when
 records are inserted in bulk, we prevent their use.

doc/development/distributed_tracing.md

@@ -14,7 +14,7 @@ According to [Open Tracing](https://opentracing.io/docs/overview/what-is-tracing
 > monitor applications, especially those built using a microservices architecture. Distributed
 > tracing helps to pinpoint where failures occur and what causes poor performance.
 
-Distributed tracing is especially helpful in understanding the life cycle of a request as it passes
+Distributed tracing is especially helpful in understanding the lifecycle of a request as it passes
 through the different components of the GitLab application. At present, Workhorse, Rails, Sidekiq,
 and Gitaly support tracing instrumentation.
 

doc/development/fe_guide/getting_started.md

@@ -10,7 +10,7 @@ This page will guide you through the Frontend development process and show you w
 
 There are a lot of things to consider for a first merge request and it can feel overwhelming. The [Frontend onboarding course](onboarding_course/index.md) provides a 6-week structured curriculum to learn how to contribute to the GitLab frontend.
 
-## Development life cycle
+## Development lifecycle
 
 ### Step 1: Preparing the issue
 

doc/development/feature_flags/controls.md

@@ -477,7 +477,7 @@ and reduces confidence in our testing suite covering all possible combinations.
 Additionally, a feature flag overwritten in some of the environments can result
 in undefined and untested system behavior.
 
-`development` type feature flags should have a short life-cycle because their purpose
+`development` type feature flags should have a short lifecycle because their purpose
 is for rolling out a persistent change. `development` feature flags that are older
 than 2 milestones are reported to engineering managers. The
 [report tool](https://gitlab.com/gitlab-org/gitlab-feature-flag-alert) runs on a

doc/development/geo/proxying.md

@@ -17,7 +17,7 @@ Proxying of Git over HTTP requests is handled by the [`gitlab-workhorse`](../../
 
 Proxying of Git over SSH traffic is handled by the [`gitlab-shell`](../../development/architecture.md#gitlab-shell) component, but the decision to proxy or not is handled by the Rails application, taking into account whether the request is push or pull, and whether the desired Git data is up-to-date.
 
-## Request life cycle
+## Request lifecycle
 
 ### Top-level view
 

doc/development/testing_guide/frontend_testing.md

@@ -1218,7 +1218,7 @@ testAction(
 <!-- vale gitlab_base.Spelling = NO -->
 
 The Axios Utils mock module located in `spec/frontend/__helpers__/mocks/axios_utils.js` contains two helper methods for Jest tests that spawn HTTP requests.
-These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its life cycle.
+These are very useful if you don't have a handle to the request's Promise, for example when a Vue component does a request as part of its lifecycle.
 
 <!-- vale gitlab_base.Spelling = YES -->
 

doc/install/openshift_and_gitlab/index.md

@@ -10,7 +10,7 @@ OpenShift - GitLab compatibility can be addressed in three different aspects. Th
 
 ## What is OpenShift
 
-OpenShift helps you to develop, deploy, and manage container-based applications. It provides you with a self-service platform to create, modify, and deploy applications on demand, thus enabling faster development and release life cycles.
+OpenShift helps you to develop, deploy, and manage container-based applications. It provides you with a self-service platform to create, modify, and deploy applications on demand, thus enabling faster development and release lifecycles.
 
 ## Use OpenShift to run GitLab self-managed
 

doc/security/hardening_nist_800_53.md

@@ -43,7 +43,7 @@ GitLab is a [DevSecOps platform](../devsecops.md) that
 integrates security throughout the development lifecycle.
 At its core, you can use GitLab to address a wide range of controls within the SA control family.
 
-#### System development life cycle
+#### System development lifecycle
 
 You can use GitLab to meet the core of this requirement. GitLab provides
 a platform where work can be

doc/user/application_security/dast/index.md

@@ -26,7 +26,7 @@ other security tools cannot detect.
 DAST is completely language agnostic and examines your application from the outside in. With a
 running application in a test environment, DAST scans can be automated in a CI/CD pipeline,
 automated on a schedule, or run independently by using on-demand scans. Using DAST during the
-software development life cycle enables teams to uncover vulnerabilities before their applications
+software development lifecycle enables teams to uncover vulnerabilities before their applications
 are in production. DAST is a foundational component of software security and should be used in
 tandem with SAST, dependency and license scanning, and secret detection, to provide a comprehensive
 security assessment of your applications.

doc/user/application_security/dast/on-demand_scan.md

@@ -20,7 +20,7 @@ Only run DAST scans against a test server.
 > - Runner tags selection [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111499) in GitLab 16.3.
 > - Browser based on-demand DAST scans available from GitLab 17.0 since [proxy-based DAST was removed in the same version](../../../update/deprecations.md#proxy-based-dast-deprecated).
 
-An on-demand DAST scan runs outside the DevOps life cycle. Changes in your repository don't trigger
+An on-demand DAST scan runs outside the DevOps lifecycle. Changes in your repository don't trigger
 the scan. You must either start it manually, or schedule it to run. For on-demand DAST scans,
 a [site profile](#site-profile) defines **what** is to be scanned, and a
 [scanner profile](#scanner-profile) defines **how** the application is to be scanned.

doc/user/application_security/dependency_scanning/dependency_scanning_sbom/index.md

@@ -29,7 +29,7 @@ aspects of inspecting the items your code uses. These items typically include ap
 dependencies that are almost always imported from external sources, rather than sourced from items
 you wrote yourself.
 
-Dependency scanning can run in the development phase of your application's life cycle. Every time a
+Dependency scanning can run in the development phase of your application's lifecycle. Every time a
 pipeline produces an SBOM report, security findings are identified and compared between the source
 and target branches. Findings and their severity are listed in the merge request, enabling you to
 proactively address the risk to your application, before the code change is committed. Security

doc/user/application_security/dependency_scanning/index.md

@@ -55,7 +55,7 @@ aspects of inspecting the items your code uses. These items typically include ap
 dependencies that are almost always imported from external sources, rather than sourced from items
 you wrote yourself.
 
-Dependency Scanning can run in the development phase of your application's life cycle. Every time a
+Dependency Scanning can run in the development phase of your application's lifecycle. Every time a
 pipeline runs, vulnerabilities are identified and compared between the source and target branches.
 Vulnerabilities and their severity are listed in the merge request, enabling you to proactively
 address the risk to your application, before the code change is committed.

doc/user/application_security/terminology/index.md

@@ -346,7 +346,7 @@ When a [report finding](#report-finding) is stored to the database, it becomes a
 
 ## Vulnerability tracking
 
-Deals with the responsibility of matching findings across scans so that a finding's life cycle can
+Deals with the responsibility of matching findings across scans so that a finding's lifecycle can
 be understood. Engineers and security teams use this information to decide whether to merge code
 changes, and to see unresolved findings and when they were introduced.
 

doc/user/project/system_notes.md

@@ -12,7 +12,7 @@ DETAILS:
 **Offering:** GitLab.com, Self-managed, GitLab Dedicated
 
 System notes are short descriptions that help you understand the history of events
-that occur during the life cycle of a GitLab object, such as:
+that occur during the lifecycle of a GitLab object, such as:
 
 - [Alerts](../../operations/incident_management/alerts.md).
 - [Designs](issues/design_management.md).

lib/gitlab/database/load_balancing/session.rb

@@ -19,8 +19,8 @@ module Gitlab
           RequestStore.delete(CACHE_KEY)
         end
 
-        def self.without_sticky_writes(&block)
-          current.ignore_writes(&block)
+        def self.without_sticky_writes(&)
+          current.ignore_writes(&)
         end
 
         def initialize
@@ -41,7 +41,7 @@ module Gitlab
           @use_primary = true
         end
 
-        def use_primary(&blk)
+        def use_primary
           used_primary = @use_primary
           @use_primary = true
           yield
@@ -49,7 +49,7 @@ module Gitlab
           @use_primary = used_primary || @performed_write
         end
 
-        def ignore_writes(&block)
+        def ignore_writes
           @ignore_writes = true
 
           yield
@@ -67,7 +67,7 @@ module Gitlab
         #
         # Write and ambiguous queries inside this block are still handled by
         # the primary.
-        def use_replicas_for_read_queries(&blk)
+        def use_replicas_for_read_queries
           previous_flag = @use_replicas_for_read_queries
           @use_replicas_for_read_queries = true
           yield
@@ -90,7 +90,7 @@ module Gitlab
         # - If the queries are about to write
         # - The current session already performed writes
         # - It prefers to use primary, aka, use_primary or use_primary! were called
-        def fallback_to_replicas_for_ambiguous_queries(&blk)
+        def fallback_to_replicas_for_ambiguous_queries
           previous_flag = @fallback_to_replicas_for_ambiguous_queries
           @fallback_to_replicas_for_ambiguous_queries = true
           yield