Automatic merge of gitlab-org/gitlab master

.gitlab/ci/rules.gitlab-ci.yml

@@ -11,7 +11,7 @@
   if: '$CI_PROJECT_NAME != "gitlab-foss" && $CI_PROJECT_NAME != "gitlab-ce" && $CI_PROJECT_NAME != "gitlabhq"'
 
 .if-jh: &if-jh
-  if: '$CI_PROJECT_PATH == "gitlab-jh/gitlab"'
+  if: '$CI_PROJECT_PATH =~ /^gitlab-(jh|cn)\/.*/'
 
 .if-default-refs: &if-default-refs
   if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH || $CI_COMMIT_REF_NAME =~ /^[\d-]+-stable(-ee)?$/ || $CI_COMMIT_REF_NAME =~ /^\d+-\d+-auto-deploy-\d+$/ || $CI_COMMIT_REF_NAME =~ /^security\// || $CI_MERGE_REQUEST_IID || $CI_COMMIT_TAG || $FORCE_GITLAB_CI'
@@ -1582,7 +1582,6 @@
       allow_failure: true
     - <<: *if-dot-com-gitlab-org-merge-request
       changes: *qa-patterns
-    - <<: *if-dot-com-gitlab-org-schedule
 
 .review:rules:review-build-cng:
   rules:

app/controllers/projects/google_cloud/service_accounts_controller.rb

@@ -54,7 +54,7 @@ class Projects::GoogleCloud::ServiceAccountsController < Projects::GoogleCloud::
 
     return if is_token_valid
 
-    return_url = project_google_cloud_service_accounts_path(project)
+    return_url = project_google_cloud_index_path(project)
     state = generate_session_key_redirect(request.url, return_url)
     @authorize_url = GoogleApi::CloudPlatform::Client.new(nil,
                                                           callback_google_api_auth_url,

doc/administration/package_information/supported_os.md

 ---
 stage: Enablement
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Supported Operating Systems
+# Supported operating systems **(FREE SELF)**
 
 GitLab officially supports LTS versions of operating systems. While OSs like
 Ubuntu have a clear distinction between LTS and non-LTS versions, there are
@@ -57,7 +57,7 @@ WARNING:
 There are currently still some [known issues and limitation](https://gitlab.com/groups/gitlab-org/-/epics/4397)
 running GitLab on ARM.
 
-## OS Versions that are no longer supported **(FREE SELF)**
+## OS Versions that are no longer supported
 
 GitLab provides omnibus packages for operating systems only until their
 EOL (End-Of-Life). After the EOL date of the OS, GitLab will stop releasing

doc/development/application_slis/index.md

@@ -180,7 +180,7 @@ alerts about the SLI in specified Slack channels. For more information, read the
 [alert routing documentation](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/uncategorized/alert-routing.md).
 In [this project](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/614)
 we are extending this so alerts for SLIs with a `feature_category`
-label in the souce metrics can also be routed.
+label in the source metrics can also be routed.
 
 For any question, please don't hesitate to create an issue in
 [the Scalability issue tracker](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues)

doc/development/backend/ruby_style_guide.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This is a GitLab-specific style guide for Ruby code.
 
-Generally, if a style is not covered by [existing rubocop rules or styleguides](../contributing/style_guides.md#ruby-rails-rspec), it shouldn't be a blocker.
+Generally, if a style is not covered by [existing Rubocop rules or style guides](../contributing/style_guides.md#ruby-rails-rspec), it shouldn't be a blocker.
 Before adding a new cop to enforce a given style, make sure to discuss it with your team.
 When the style is approved by a backend EM or by a BE staff eng, add a new section to this page to
 document the new rule. For every new guideline, add it in a new section and link the discussion from the section's

doc/development/database/loose_foreign_keys.md

@@ -214,5 +214,5 @@ permission checks.
 We considered using these Rails features as an alternative to foreign keys but there are several problems which include:
 
 1. These run on a different connection in the context of a transaction [which we do not allow](multiple_databases.md#removing-cross-database-transactions).
-1. These can lead to severe performance degredation as we load all records from PostgreSQL, loop over them in Ruby, and call individual `DELETE` queries.
+1. These can lead to severe performance degradation as we load all records from PostgreSQL, loop over them in Ruby, and call individual `DELETE` queries.
 1. These can miss data as they only cover the case when the `destroy` method is called directly on the model. There are other cases including `delete_all` and cascading deletes from another parent table that could mean these are missed.

doc/development/feature_flags/controls.md

@@ -12,7 +12,8 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 To be able to turn on/off features behind feature flags in any of the
 GitLab Inc. provided environments such as staging and production, you need to
 have access to the [ChatOps](../chatops_on_gitlabcom.md) bot. The ChatOps bot
-is currently running on the ops instance, which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
+is currently running on the ops instance, which is different from
+[GitLab.com](https://gitlab.com) or [`dev.gitlab.org`](https://dev.gitlab.org).
 
 Follow the ChatOps document to [request access](../chatops_on_gitlabcom.md#requesting-access).
 
@@ -35,12 +36,12 @@ This allows you to separate rolling out a feature from a deploy, making it
 easier to measure the impact of both separately.
 
 The GitLab feature library (using
-[Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
-Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
+[Flipper](https://github.com/jnunemaker/flipper), and covered in the
+[Feature Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
 time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
 
-For an up to date list of feature flag commands please see [the source
-code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
+For an up to date list of feature flag commands please see
+[the source code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).
 Note that all the examples in that file must be preceded by
 `/chatops run`.
 
@@ -50,15 +51,16 @@ change feature flags or you do not [have access](#access).
 
 ### Enabling a feature for pre-production testing
 
-As a first step in a feature rollout, you should enable the feature on <https://about.staging.gitlab.com>
-and <https://dev.gitlab.org>.
+As a first step in a feature rollout, you should enable the feature on
+[`about.staging.gitlab.com`](https://about.staging.gitlab.com)
+and [`dev.gitlab.org`](https://dev.gitlab.org).
 
 These two environments have different scopes.
 `dev.gitlab.org` is a production CE environment that has internal GitLab Inc.
 traffic and is used for some development and other related work.
 `staging.gitlab.com` has a smaller subset of GitLab.com database and repositories
 and does not have regular traffic. Staging is an EE instance and can give you
-a (very) rough estimate of how your feature will look/behave on GitLab.com.
+a (very) rough estimate of how your feature will look and behave on GitLab.com.
 Both of these instances are connected to Sentry so make sure you check the projects
 there for any exceptions while testing your feature after enabling the feature flag.
 
@@ -97,7 +99,7 @@ Guidelines:
 #### Process
 
 When enabling a feature flag rollout, the system will automatically block the
-chatops command from succeeding if there are active `"severity::1"` or `~"severity::2"`
+ChatOps command from succeeding if there are active `"severity::1"` or `~"severity::2"`
 incidents or in-progress change issues, for example:
 
 ```shell
@@ -227,7 +229,7 @@ Note, that if an actor based feature gate is present, switching the
 `default_enabled` attribute of the YAML definition from `false` to `true`
 will not have any effect. The feature gate must be deleted first.
 
-For example, a feature flag is set via chatops:
+For example, a feature flag is set via ChatOps:
 
 ```shell
 /chatops run feature set --project=gitlab-org/gitlab some_feature true
@@ -265,7 +267,7 @@ To disable a feature flag that has been enabled for a specific project you can r
 
 You cannot selectively disable feature flags for a specific project/group/user without applying a [specific method of implementing](index.md#selectively-disable-by-actor) the feature flags.
 
-If a feature flag is disabled via chatops, that will take precedence over the `default_enabled` value in the YML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com.
+If a feature flag is disabled via ChatOps, that will take precedence over the `default_enabled` value in the YML. In other words, you could have a feature enabled for on-premise installations but not for GitLab.com.
 
 ### Feature flag change logging
 

doc/development/merge_request_performance_guidelines.md

@@ -205,7 +205,7 @@ Keeping the old behavior requires marking CTEs with the keyword `MATERIALIZED`.
 When building CTE statements, use the `Gitlab::SQL::CTE` class [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56976) in GitLab 13.11.
 By default, this `Gitlab::SQL::CTE` class forces materialization through adding the `MATERIALIZED` keyword for PostgreSQL 12 and higher.
 `Gitlab::SQL::CTE` automatically omits materialization when PostgreSQL 11 is running
-(this behavior is implemented using a custom arel node `Gitlab::Database::AsWithMaterialized` under the surface).
+(this behavior is implemented using a custom Arel node `Gitlab::Database::AsWithMaterialized` under the surface).
 
 WARNING:
 We plan to drop the support for PostgreSQL 11. Upgrading to GitLab 14.0 requires PostgreSQL 12 or higher.

doc/development/performance.md

@@ -365,7 +365,7 @@ This patch is available by default for
 [GCK](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/merge_requests/149)
 and can additionally be enabled for [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/advanced.md#apply-custom-patches-for-ruby).
 
-This patch provides the following metrics that make it easier to understand efficiency of memory use for a given codepath:
+This patch provides the following metrics that make it easier to understand efficiency of memory use for a given code path:
 
 - `mem_total_bytes`: the number of bytes consumed both due to new objects being allocated into existing object slots
                      plus additional memory allocated for large objects (that is, `mem_bytes + slot_size * mem_objects`).
@@ -384,7 +384,7 @@ and `100M mem_bytes`. You can view the current usage on [GitLab.com](https://log
 There are two ways of measuring your own code:
 
 1. Review `api_json.log`, `development_json.log`, `sidekiq.log` that includes memory allocation counters.
-1. Use `Gitlab::Memory::Instrumentation.with_memory_allocations` for a given codeblock and log it.
+1. Use `Gitlab::Memory::Instrumentation.with_memory_allocations` for a given code block and log it.
 1. Use [Measuring module](service_measurement.md)
 
 ```json

doc/development/rails_update.md

@@ -71,7 +71,7 @@ To efficiently and quickly find which Rails change caused the spec failure you c
     gem 'rails', ENV['RAILS_VERSION'], path: ENV['RAILS_FOLDER']
     ```
 
-1. Set the `RAILS_FOLDER` env variable with the folder you cloned Rails into:
+1. Set the `RAILS_FOLDER` environment variable with the folder you cloned Rails into:
 
     ```shell
     export RAILS_FOLDER="<GDK_FOLDER>/rails"

doc/development/ruby_upgrade.md

@@ -190,7 +190,7 @@ via `gdk update`.
 This pause is a good time to assess the risk of this upgrade for GitLab SaaS.
 For Ruby upgrades that are high risk, such as major version upgrades, it is recommended to
 coordinate the changes with the infrastructure team through a [change management request](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/).
-Create this issue early to give everyone enough time to schedule and prepare changes.  
+Create this issue early to give everyone enough time to schedule and prepare changes.
 
 ### Make it the default Ruby
 
@@ -205,7 +205,7 @@ in that repository. This change is only necessary when the minor or major versio
 ([example](https://gitlab.com/gitlab-org/gitlab-compose-kit/-/merge_requests/176).)
 
 As mentioned above, if the impact of the Ruby upgrade on SaaS availability is uncertain, it is
-prudent to skip this step until you have verified that it runs smootly in production via a staged
+prudent to skip this step until you have verified that it runs smoothly in production via a staged
 rollout. In this case, go to the next step first, and then, after the verification period has passed, promote
 the new Ruby to be the new default.
 

doc/development/stage_group_dashboards.md

@@ -60,8 +60,8 @@ component can have 2 indicators:
 
    We're working on making this target configurable per endpoint in [this
    project](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/525). Learn
-   how to [customize the request
-   apdex](application_slis/rails_request_apdex.md), this new apdex
+   how to
+   [customize the request Apdex](application_slis/rails_request_apdex.md), this new Apdex
    measurement is not yet part of the error budget.
 
    For Sidekiq job execution, the threshold depends on the [job

doc/development/testing_guide/best_practices.md

@@ -964,7 +964,7 @@ creates and deletes indices between examples to ensure a clean index, so that th
 for polluting the tests with nonessential data.
 Most tests for Elasticsearch logic relate to:
 
-- Creating data in Postgres and waiting for it to be indexed in Elasticsearch.
+- Creating data in PostgreSQL and waiting for it to be indexed in Elasticsearch.
 - Searching for that data.
 - Ensuring that the test gives the expected result.
 
@@ -980,7 +980,7 @@ You do NOT need to add `:clean_gitlab_redis_shared_state` manually.
 
 Specs using Elasticsearch require that you:
 
-- Create data in Postgres and then index it into Elasticsearch.
+- Create data in PostgreSQL and then index it into Elasticsearch.
 - Enable Application Settings for Elasticsearch (which is disabled by default).
 
 To do so, use:
@@ -994,7 +994,7 @@ end
 Additionally, you can use the `ensure_elasticsearch_index!` method to overcome the asynchronous nature of Elasticsearch.
 It uses the [Elasticsearch Refresh API](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-refresh.html#refresh-api-desc)
 to make sure all operations performed on an index since the last refresh are available for search. This method is typically
-called after loading data into Postgres to ensure the data is indexed and searchable.
+called after loading data into PostgreSQL to ensure the data is indexed and searchable.
 
 #### Test Snowplow events
 

doc/development/testing_guide/review_apps.md

@@ -15,7 +15,6 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be
 - for merge requests with CI config changes
 - for merge requests with frontend changes
 - for merge requests with QA changes
-- for scheduled pipelines
 - the MR has the `pipeline:run-review-app` label set
 
 ## QA runs on Review Apps

doc/install/aws/gitlab_hybrid_on_aws.md

@@ -131,7 +131,7 @@ Some services, such as log aggregation, outbound email are not specified by GitL
 - TBD
 
  **Deploy Now**
- Deploy Now links leverage the AWS Quick Start automation and only prepopulate the number of instances and instance types for the Quick Start based on the Bill of Meterials below. You must provide appropriate input for all other parameters by following the guidance in the [Quick Start documentation's Deployment steps](https://aws-quickstart.github.io/quickstart-eks-gitlab/#_deployment_steps) section.
+ Deploy Now links leverage the AWS Quick Start automation and only pre-populate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the [Quick Start documentation's Deployment steps](https://aws-quickstart.github.io/quickstart-eks-gitlab/#_deployment_steps) section.
 
 - **Deploy Now: AWS Quick Start for 2 AZs**
 - **Deploy Now: AWS Quick Start for 3 AZs**
@@ -184,7 +184,7 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 
 **Deploy Now**
 
-Deploy Now links leverage the AWS Quick Start automation and only prepopulate the number of instances and instance types for the Quick Start based on the Bill of Meterials below. You must provide appropriate input for all other parameters by following the guidance in the [Quick Start documentation's Deployment steps](https://aws-quickstart.github.io/quickstart-eks-gitlab/#_deployment_steps) section.
+Deploy Now links leverage the AWS Quick Start automation and only pre-populate the number of instances and instance types for the Quick Start based on the Bill of Materials below. You must provide appropriate input for all other parameters by following the guidance in the [Quick Start documentation's Deployment steps](https://aws-quickstart.github.io/quickstart-eks-gitlab/#_deployment_steps) section.
 
 - **[Deploy Now: AWS Quick Start for 2 AZs](https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/quickcreate?templateUrl=https://aws-quickstart.s3.us-east-1.amazonaws.com/quickstart-eks-gitlab/templates/gitlab-entry-new-vpc.template.yaml&stackName=Gitlab-EKS-3K-Users-2AZs&param_NumberOfAZs=2&param_NodeInstanceType=c5.2xlarge&param_NumberOfNodes=3&param_MaxNumberOfNodes=3&param_DBInstanceClass=db.r6g.xlarge&param_CacheNodes=2&param_CacheNodeType=cache.m6g.large&param_GitalyInstanceType=m5.large&param_NumberOfGitalyReplicas=3&param_PraefectInstanceType=c5.large&param_NumberOfPraefectReplicas=3)**
 - **[Deploy Now: AWS Quick Start for 3 AZs](https://us-east-2.console.aws.amazon.com/cloudformation/home?region=us-east-2#/stacks/quickcreate?templateUrl=https://aws-quickstart.s3.us-east-1.amazonaws.com/quickstart-eks-gitlab/templates/gitlab-entry-new-vpc.template.yaml&stackName=Gitlab-EKS-3K-Users-3AZs&param_NumberOfAZs=3&param_NodeInstanceType=c5.2xlarge&param_NumberOfNodes=3&param_MaxNumberOfNodes=3&param_DBInstanceClass=db.r6g.xlarge&param_CacheNodes=3&param_CacheNodeType=cache.m6g.large&param_GitalyInstanceType=m5.large&param_NumberOfGitalyReplicas=3&param_PraefectInstanceType=c5.large&param_NumberOfPraefectReplicas=3)**

doc/install/aws/gitlab_sre_for_aws.md

@@ -10,7 +10,7 @@ description: Doing SRE for GitLab instances and runners on AWS.
 
 ## Gitaly SRE considerations
 
-Gitaly is an embedded service for Git Repository Storage. Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries that must be used on the service side of GitLab. Here is indepth technical reading on the topic:
+Gitaly is an embedded service for Git Repository Storage. Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries that must be used on the service side of GitLab. Here is in-depth technical reading on the topic:
 
 ### Why Gitaly was built
 
@@ -66,14 +66,14 @@ All recommendations are for production configurations, including performance tes
 
 #### Network I/O recommendations
 
-- Use only instance types [from the list of ones that support ENA advanced networking]( https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table) to ensure that cluster replication latency is not due to instance level network I/O bottlenecking.
+- Use only instance types [from the list of ones that support ENA advanced networking]( https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table) to ensure that cluster replication latency is not due to instance level network I/O bottlenecks.
 - Choose instances with sizes with more than 10 Gbps - but only if needed and only when having proven a node level network bottleneck with monitoring and/or stress testing.
 
 **To accommodate:**
 
 - Gitaly nodes do the main work of streaming repositories for push and pull operations (to add development endpoints, and to CI/CD).
 - Gitaly servers need reasonable low latency between cluster nodes and with Praefect services in order for the cluster to maintain operational and data integrity.
-- Gitaly nodes should be selected with network bottlenecking avoidance as a primary consideration.
+- Gitaly nodes should be selected with network bottleneck avoidance as a primary consideration.
 - Gitaly nodes should be monitored for network saturation.
 - Not all networking issues can be solved through optimizing the node level networking:
   - Gitaly cluster node replication depends on all networking between nodes.

doc/install/aws/manual_install_aws.md

@@ -28,7 +28,7 @@ The Infrastructure as Code tooling [GitLab Environment Tool (GET)](https://gitla
 
 ### Getting started for production-grade Cloud Native Hybrid GitLab
 
-For the Cloud Native Hybrid architectures there are two Infrastructure as Code options which are compared in GitLab Cloud Native Hybrid on AWS EKS implementation pattern in the section [Available Infrastructure as Code for GitLab Cloud Native Hybrid](gitlab_hybrid_on_aws.md#available-infrastructure-as-code-for-gitlab-cloud-native-hybrid). It compares the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit/-/tree/master) to the AWS Quick Start for GitLab Cloud Native Hybrid on EKS which was codeveloped by GitLab and AWS. GET and the AWS Quick Start are both open source so anyone can build on top of them and contribute improvements to them.
+For the Cloud Native Hybrid architectures there are two Infrastructure as Code options which are compared in GitLab Cloud Native Hybrid on AWS EKS implementation pattern in the section [Available Infrastructure as Code for GitLab Cloud Native Hybrid](gitlab_hybrid_on_aws.md#available-infrastructure-as-code-for-gitlab-cloud-native-hybrid). It compares the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit/-/tree/master) to the AWS Quick Start for GitLab Cloud Native Hybrid on EKS which was co-developed by GitLab and AWS. GET and the AWS Quick Start are both open source so anyone can build on top of them and contribute improvements to them.
 
 ## Introduction
 
@@ -533,7 +533,7 @@ gitlab=# \q
    ```ruby
    # Disable the built-in Postgres
     postgresql['enable'] = false
-   
+
    # Fill in the connection details
    gitlab_rails['db_adapter'] = "postgresql"
    gitlab_rails['db_encoding'] = "unicode"
@@ -549,7 +549,7 @@ gitlab=# \q
    ```ruby
    # Disable the built-in Redis
    redis['enable'] = false
-   
+
    # Fill in the connection details
    gitlab_rails['redis_host'] = "<redis-endpoint>"
    gitlab_rails['redis_port'] = 6379

doc/install/docker.md

@@ -199,11 +199,11 @@ configure and deploy your
 Docker-based GitLab installation in a swarm cluster.
 
 In swarm mode you can leverage [Docker secrets](https://docs.docker.com/engine/swarm/secrets/)
-and [Docker configs](https://docs.docker.com/engine/swarm/configs/) to efficiently and securely deploy your GitLab instance.
+and [Docker configurations](https://docs.docker.com/engine/swarm/configs/) to efficiently and securely deploy your GitLab instance.
 Secrets can be used to securely pass your initial root password without exposing it as an environment variable.
-Configs can help you to keep your GitLab image as generic as possible.
+Configurations can help you to keep your GitLab image as generic as possible.
 
-Here's an example that deploys GitLab with four runners as a [stack](https://docs.docker.com/get-started/part5/), using secrets and configs:
+Here's an example that deploys GitLab with four runners as a [stack](https://docs.docker.com/get-started/part5/), using secrets and configurations:
 
 1. [Set up a Docker swarm](https://docs.docker.com/engine/swarm/swarm-tutorial/).
 1. Create a `docker-compose.yml` file:
@@ -643,4 +643,4 @@ purpose.
 
 ### Docker containers exhausts space due to the `json-file`
 
-Docker's [default logging driver is `json-file`](https://docs.docker.com/config/containers/logging/configure/#configure-the-default-logging-driver), which performs no log rotation by default. As a result of this lack of rotation, log files stored by the `json-file` driver can consume a significant amount of disk space for containers that generate a lot of output. This can lead to disk space exhaustion. To address this, use [journald](https://docs.docker.com/config/containers/logging/journald/) as the logging driver when available, or [another supported driver](https://docs.docker.com/config/containers/logging/configure/#supported-logging-drivers) with native rotation support.
+Docker's [default logging driver is `json-file`](https://docs.docker.com/config/containers/logging/configure/#configure-the-default-logging-driver), which performs no log rotation by default. As a result of this lack of rotation, log files stored by the `json-file` driver can consume a significant amount of disk space for containers that generate a lot of output. This can lead to disk space exhaustion. To address this, use [`journald`](https://docs.docker.com/config/containers/logging/journald/) as the logging driver when available, or [another supported driver](https://docs.docker.com/config/containers/logging/configure/#supported-logging-drivers) with native rotation support.

doc/update/plan_your_upgrade.md

@@ -71,7 +71,7 @@ comprised of a way to back up the instance and a way to restore it.
 
 ### Back up GitLab
 
-Create a backup of GitLab and all its data (database, repos, uploads, builds,
+Create a backup of GitLab and all its data (database, repositories, uploads, builds,
 artifacts, LFS objects, registry, pages). This is vital for making it possible
 to roll back GitLab to a working state if there's a problem with the upgrade:
 

ee/app/assets/javascripts/vue_merge_request_widget/components/blocking_merge_requests/blocking_merge_requests_report.vue

@@ -113,7 +113,7 @@ export default {
   >
     <template #success>
       {{ __('All merge request dependencies have been merged') }}
-      <span class="text-secondary">
+      <span class="text-secondary gl-ml-1">
         {{
           sprintf(__('(%{mrCount} merged)'), {
             mrCount: blockingMergeRequests.total_count - unmergedBlockingMergeRequests.length,

ee/app/models/ee/application_setting.rb

@@ -316,8 +316,8 @@ module EE
       elasticsearch_url.map do |url|
         uri = URI.parse(url)
 
-        uri.user = elasticsearch_username
-        uri.password = elasticsearch_password.presence || ''
+        uri.user = URI.encode_www_form_component(elasticsearch_username)
+        uri.password = URI.encode_www_form_component(elasticsearch_password)
         uri.to_s
       end
     end

ee/spec/models/application_setting_spec.rb

@@ -374,6 +374,17 @@ RSpec.describe ApplicationSetting do
 
       expect(setting.elasticsearch_url_with_credentials).to eq(%w[http://username:password@example.com https://test:test@example2.com:9200])
     end
+
+    it 'encodes the credentials' do
+      setting.elasticsearch_url = 'http://username:password@example.com,https://test:test@example2.com:9200'
+      setting.elasticsearch_username = 'foo/admin'
+      setting.elasticsearch_password = 'b@r'
+
+      expect(setting.elasticsearch_url_with_credentials).to eq(%w[
+        http://foo%2Fadmin:b%40r@example.com
+        https://foo%2Fadmin:b%40r@example2.com:9200
+      ])
+    end
   end
 
   describe '#elasticsearch_password' do

package.json

@@ -57,7 +57,7 @@
     "@gitlab/favicon-overlay": "2.0.0",
     "@gitlab/svgs": "1.225.0",
     "@gitlab/tributejs": "1.0.0",
-    "@gitlab/ui": "32.42.0",
+    "@gitlab/ui": "32.43.0",
     "@gitlab/visual-review-tools": "1.6.1",
     "@rails/actioncable": "6.1.4-1",
     "@rails/ujs": "6.1.4-1",

yarn.lock

@@ -924,10 +924,10 @@
   resolved "https://registry.yarnpkg.com/@gitlab/tributejs/-/tributejs-1.0.0.tgz#672befa222aeffc83e7d799b0500a7a4418e59b8"
   integrity sha512-nmKw1+hB6MHvlmPz63yPwVs1qQkycHwsKgxpEbzmky16Y6mL4EJMk3w1b8QlOAF/AIAzjCERPhe/R4MJiohbZw==
 
-"@gitlab/ui@32.42.0":
-  version "32.42.0"
-  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-32.42.0.tgz#e45299124b08a6804fff5dc9358d93b9d02680c6"
-  integrity sha512-EGV91sM38Tp0eEsK/xeBE6Sd1nOiLO0u5pSNU9fJgfwDQuTpUC/YV5OeKpE4drnOQpxLGUOeGOFogAzv9zcbDg==
+"@gitlab/ui@32.43.0":
+  version "32.43.0"
+  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-32.43.0.tgz#950d189ff50693bdec29edb3fd002aa409410d3f"
+  integrity sha512-OTKRW3PahpONXirVvV+jBMNVfZLgQtE7x2Q13cBfgDYt5fsPpHstUFv4+hKzV6D/aoVDRuw80HjAcnw/QtS73A==
   dependencies:
     "@babel/standalone" "^7.0.0"
     bootstrap-vue "2.20.1"