Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/issuable_form.js

@@ -51,15 +51,16 @@ export default class IssuableForm {
     this.resetAutosave = this.resetAutosave.bind(this);
     this.handleSubmit = this.handleSubmit.bind(this);
     /* eslint-disable @gitlab/require-i18n-strings */
-    this.wipRegex = new RegExp(
+    // prettier-ignore
+    this.draftRegex = new RegExp(
       '^\\s*(' + // Line start, then any amount of leading whitespace
         'draft\\s-\\s' + // Draft_-_ where "_" are *exactly* one whitespace
-        '|\\[draft\\]\\s*' + // [Draft] or [WIP] and any following whitespace
-        '|draft:\\s*' + // Draft: or WIP: and any following whitespace
-        '|draft\\s+' + // Draft_ or WIP_ where "_" is at least one whitespace
+        '|\\[draft\\]\\s*' + // [Draft] and any following whitespace
+        '|draft:\\s*' + // Draft: and any following whitespace
+        '|draft\\s+' + // Draft_ where "_" is at least one whitespace
         '|\\(draft\\)\\s*' + // (Draft) and any following whitespace
-        ')+' + // At least one repeated match of the preceding parenthetical
-        '\\s*', // Any amount of trailing whitespace
+      ')+' + // At least one repeated match of the preceding parenthetical
+      '\\s*', // Any amount of trailing whitespace
       'i', // Match any case(s)
     );
     /* eslint-enable @gitlab/require-i18n-strings */
@@ -144,7 +145,7 @@ export default class IssuableForm {
   }
 
   workInProgress() {
-    return this.wipRegex.test(this.titleField.val());
+    return this.draftRegex.test(this.titleField.val());
   }
 
   renderWipExplanation() {
@@ -170,7 +171,7 @@ export default class IssuableForm {
   }
 
   removeWip() {
-    return this.titleField.val(this.titleField.val().replace(this.wipRegex, ''));
+    return this.titleField.val(this.titleField.val().replace(this.draftRegex, ''));
   }
 
   addWip() {

app/models/ci/freeze_period.rb

@@ -9,7 +9,7 @@ module Ci
 
     belongs_to :project, inverse_of: :freeze_periods
 
-    strip_attributes :freeze_start, :freeze_end
+    strip_attributes! :freeze_start, :freeze_end
 
     validates :freeze_start, cron: true, presence: true
     validates :freeze_end, cron: true, presence: true

app/models/ci/pipeline_schedule.rb

@@ -24,7 +24,7 @@ module Ci
     validates :description, presence: true
     validates :variables, nested_attributes_duplicates: true
 
-    strip_attributes :cron
+    strip_attributes! :cron
 
     scope :active, -> { where(active: true) }
     scope :inactive, -> { where(active: false) }

app/models/concerns/issuable.rb

@@ -152,7 +152,7 @@ module Issuable
     participant :notes_with_associations
     participant :assignees
 
-    strip_attributes :title
+    strip_attributes! :title
 
     class << self
       def labels_hash

app/models/concerns/strip_attribute.rb

@@ -7,7 +7,7 @@
 # Usage:
 #
 #     class Milestone < ApplicationRecord
-#       strip_attributes :title
+#       strip_attributes! :title
 #     end
 #
 #
@@ -15,7 +15,7 @@ module StripAttribute
   extend ActiveSupport::Concern
 
   class_methods do
-    def strip_attributes(*attrs)
+    def strip_attributes!(*attrs)
       strip_attrs.concat(attrs)
     end
 
@@ -25,10 +25,10 @@ module StripAttribute
   end
 
   included do
-    before_validation :strip_attributes
+    before_validation :strip_attributes!
   end
 
-  def strip_attributes
+  def strip_attributes!
     self.class.strip_attrs.each do |attr|
       self[attr].strip! if self[attr] && self[attr].respond_to?(:strip!)
     end

app/models/concerns/timebox.rb

@@ -106,7 +106,7 @@ module Timebox
         .where('due_date is NULL or due_date >= ?', start_date)
     end
 
-    strip_attributes :title
+    strip_attributes! :title
 
     alias_attribute :name, :title
   end

config/feature_flags/development/dast_meta_tag_validation.yml

@@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/337711
 milestone: '14.2'
 type: development
 group: group::dynamic analysis
-default_enabled: false
+default_enabled: true

config/feature_flags/development/load_balancing_for_export_workers.yml

@@ -0,0 +1,8 @@
+---
+name: load_balancing_for_export_workers
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68153
+rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/338615
+milestone: '14.2'
+type: development
+group: group::import
+default_enabled: false

db/post_migrate/20210730170823_schedule_security_setting_creation.rb

@@ -0,0 +1,26 @@
+# frozen_string_literal: true
+
+class ScheduleSecuritySettingCreation < ActiveRecord::Migration[6.1]
+  include Gitlab::Database::MigrationHelpers
+
+  MIGRATION = 'CreateSecuritySetting'
+  BATCH_SIZE = 1000
+  INTERVAL = 5.minutes.to_i
+
+  disable_ddl_transaction!
+
+  def up
+    return unless Gitlab.ee? # Security Settings available only in EE version
+
+    queue_background_migration_jobs_by_range_at_intervals(
+      define_batchable_model('projects'),
+      MIGRATION,
+      INTERVAL,
+      batch_size: BATCH_SIZE
+    )
+  end
+
+  # We're adding data so no need for rollback
+  def down
+  end
+end

db/schema_migrations/20210730170823

@@ -0,0 +1 @@
+33b260626d65347a80240ffdce5f9e2abfc578e8151ed41f1ca9b16ef2654853

doc/administration/raketasks/doctor.md

@@ -70,6 +70,7 @@ bundle exec rake gitlab:doctor:secrets RAILS_ENV=production VERBOSE=1
 **Example verbose output**
 
 <!-- vale gitlab.SentenceSpacing = NO -->
+
 ```plaintext
 I, [2020-06-11T17:17:54.951815 #27148]  INFO -- : Checking encrypted values in the database
 I, [2020-06-11T17:18:12.677708 #27148]  INFO -- : - ApplicationSetting failures: 0
@@ -83,4 +84,5 @@ I, [2020-06-11T17:18:15.575533 #27148]  INFO -- : - ScimOauthAccessToken failure
 I, [2020-06-11T17:18:15.575678 #27148]  INFO -- : Total: 1 row(s) affected
 I, [2020-06-11T17:18:15.575711 #27148]  INFO -- : Done!
 ```
+
 <!-- vale gitlab.SentenceSpacing = YES -->

doc/api/project_badges.md

@@ -21,6 +21,7 @@ Badges support placeholders that are replaced in real time in both the link and
 - **%{commit_sha}**: Replaced by the last project's commit SHA.
 
 <!-- vale gitlab.Spelling = YES -->
+
 ## List all badges of a project
 
 Gets a list of a project's badges and its group badges.

doc/api/settings.md

@@ -330,7 +330,7 @@ listed in the descriptions of the relevant settings.
 | `html_emails_enabled`                    | boolean          | no                                   | Enable HTML emails. |
 | `import_sources`                         | array of strings | no                                   | Sources to allow project import from, possible values: `github`, `bitbucket`, `bitbucket_server`, `gitlab`, `fogbugz`, `git`, `gitlab_project`, `gitea`, `manifest`, and `phabricator`. |
 | `in_product_marketing_emails_enabled`    | boolean          | no                                   | Enable [in-product marketing emails](../user/profile/notifications.md#global-notification-settings). Enabled by default. |
-| `invisible_captcha_enabled`              | boolean          | no                                   | <!-- vale gitlab.Spelling = NO --> Enable Invisible Captcha <!-- vale gitlab.Spelling = YES --> spam detection during sign-up. Disabled by default. |
+| `invisible_captcha_enabled`              | boolean          | no                                   | Enable Invisible CAPTCHA spam detection during sign-up. Disabled by default. |
 | `issues_create_limit`                    | integer          | no                                   | Max number of issue creation requests per minute per user. Disabled by default.|
 | `keep_latest_artifact`                   | boolean          | no                                   | Prevent the deletion of the artifacts from the most recent successful jobs, regardless of the expiry time. Enabled by default. |
 | `local_markdown_version`                 | integer          | no                                   | Increase this value when any cached Markdown should be invalidated. |

doc/ci/pipelines/parent_child_pipelines.md

@@ -157,9 +157,13 @@ build a matrix of targets and architectures.
 For an overview, see [Create child pipelines using dynamically generated configurations](https://youtu.be/nMdfus2JWHM).
 
 <!-- vale gitlab.Spelling = NO -->
+
 We also have an example project using
 [Dynamic Child Pipelines with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet)
-which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime. You could use a similar process for other templating languages like [Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/).
+which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime.
+You could use a similar process for other templating languages like
+[Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/).
+
 <!-- vale gitlab.Spelling = NO -->
 
 The artifact path is parsed by GitLab, not the runner, so the path must match the

doc/ci/yaml/index.md

@@ -126,6 +126,15 @@ Use `stages` to define stages that contain groups of jobs. `stages` is defined g
 for the pipeline. Use [`stage`](#stage) in a job to define which stage the job is
 part of.
 
+If `stages` is not defined in the `.gitlab-ci.yml` file, then the default
+pipeline stages are:
+
+- [`.pre`](#stage-pre)
+- `build`
+- `test`
+- `deploy`
+- [`.post`](#stage-post)
+
 The order of the `stages` items defines the execution order for jobs:
 
 - Jobs in the same stage run in parallel.
@@ -148,9 +157,6 @@ stages:
 If any job fails, the pipeline is marked as `failed` and jobs in later stages do not
 start. Jobs in the current stage are not stopped and continue to run.
 
-If no `stages` are defined in the `.gitlab-ci.yml` file, then `build`, `test` and `deploy`
-are the default pipeline stages.
-
 If a job does not specify a [`stage`](#stage), the job is assigned the `test` stage.
 
 If a stage is defined, but no jobs use it, the stage is not visible in the pipeline. This is
@@ -816,19 +822,19 @@ If a job times out or is cancelled, the `after_script` commands do not execute.
 
 ### `stage`
 
-Use `stage` to define which stage a job runs in. Jobs in the same
-`stage` can execute in parallel (subject to [certain conditions](#use-your-own-runners)).
+Use `stage` to define which [stage](#stages) a job runs in. Jobs in the same
+`stage` can execute in parallel (see **Additional details**).
 
-Jobs without a `stage` entry use the `test` stage by default. If you do not define
-[`stages`](#stages) in the pipeline, you can use the 5 default stages, which execute in
-this order:
+If `stage` is not defined, the job uses the `test` stage by default.
 
-- [`.pre`](#pre-and-post)
-- `build`
-- `test`
-- `deploy`
-- [`.post`](#pre-and-post)
-For example:
+**Keyword type**: Job keyword. You can use it only as part of a job.
+
+**Possible inputs**: An array including any number of stage names. Stage names can be:
+
+- The [default stages](#stages).
+- User-defined stages.
+
+**Example of `stage`**:
 
 ```yaml
 stages:
@@ -836,76 +842,101 @@ stages:
   - test
   - deploy
 
-job 0:
-  stage: .pre
-  script: make something useful before build stage
-
-job 1:
+job1:
   stage: build
-  script: make build dependencies
+  script:
+    - echo "This job compiles code."
 
-job 2:
-  stage: build
-  script: make build artifacts
-
-job 3:
+job2:
   stage: test
-  script: make test
+  script:
+    - echo "This job tests the compiled code. It runs when the build stage completes."
 
-job 4:
+job3:
+  script:
+    - echo "This job also runs in the test stage".
+
+job4:
   stage: deploy
-  script: make deploy
-
-job 5:
-  stage: .post
-  script: make something useful at the end of pipeline
+  script:
+    - echo "This job deploys the code. It runs when the test stage completes."
 ```
 
-#### Use your own runners
+**Additional details**:
 
-When you use your own runners, each runner runs only one job at a time by default.
-Jobs can run in parallel if they run on different runners.
+- Jobs can run in parallel if they run on different runners.
+- If you have only one runner, jobs can run in parallel if the runner's
+  [`concurrent` setting](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section)
+  is greater than `1`.
 
-If you have only one runner, jobs can run in parallel if the runner's
-[`concurrent` setting](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section)
-is greater than `1`.
-
-#### `.pre` and `.post`
+#### `stage: .pre`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31441) in GitLab 12.4.
 
-Use `pre` and `post` for jobs that need to run first or last in a pipeline.
-
-- `.pre` is guaranteed to always be the first stage in a pipeline.
-- `.post` is guaranteed to always be the last stage in a pipeline.
-
-User-defined stages are executed after `.pre` and before `.post`.
+Use the `.pre` stage to make a job run at the start of a pipeline. `.pre` is
+always the first stage in a pipeline. User-defined stages execute after `.pre`.
+You do not need to define `.pre` in [`stages`](#stages).
 
 You must have a job in at least one stage other than `.pre` or `.post`.
 
-You can't change the order of `.pre` and `.post`, even if you define them out of order in the `.gitlab-ci.yml` file.
-For example, the following configurations are equivalent:
+**Keyword type**: You can only use it with a job's `stage` keyword.
+
+**Example of `stage: .pre`**:
 
 ```yaml
 stages:
-  - .pre
-  - a
-  - b
-  - .post
+  - build
+  - test
+
+job1:
+  stage: build
+  script:
+    - echo "This job runs in the build stage."
+
+first-job:
+  stage: .pre
+  script:
+    - echo "This job runs in the .pre stage, before all other stages."
+
+job2:
+  stage: test
+  script:
+    - echo "This job runs in the test stage."
 ```
 
-```yaml
-stages:
-  - a
-  - .pre
-  - b
-  - .post
-```
+#### `stage: .post`
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31441) in GitLab 12.4.
+
+Use the `.post` stage to make a job run at the end of a pipeline. `.post`
+is always the last stage in a pipeline. User-defined stages execute before `.post`.
+You do not need to define `.post` in [`stages`](#stages).
+
+You must have a job in at least one stage other than `.pre` or `.post`.
+
+**Keyword type**: You can only use it with a job's `stage` keyword.
+
+**Example of `stage: .post`**:
 
 ```yaml
 stages:
-  - a
-  - b
+  - build
+  - test
+
+job1:
+  stage: build
+  script:
+    - echo "This job runs in the build stage."
+
+last-job:
+  stage: .post
+  script:
+    - echo "This job runs in the .post stage, after all other stages."
+
+job2:
+  stage: test
+  script:
+    - echo "This job runs in the test stage."
 ```
 
 ### `extends`
@@ -3537,7 +3568,7 @@ but with different variable values for each instance of the job.
 There can be from 2 to 50 jobs.
 
 Jobs can only run in parallel if there are multiple runners, or a single runner is
-[configured to run multiple jobs concurrently](#use-your-own-runners).
+configured to run multiple jobs concurrently.
 
 Every job gets the same `CI_NODE_TOTAL` [CI/CD variable](../variables/index.md#predefined-cicd-variables) value, and a unique `CI_NODE_INDEX` value.
 

doc/development/api_graphql_styleguide.md

@@ -11,9 +11,12 @@ This document outlines the style guide for the GitLab [GraphQL API](../api/graph
 ## How GitLab implements GraphQL
 
 <!-- vale gitlab.Spelling = NO -->
+
 We use the [GraphQL Ruby gem](https://graphql-ruby.org/) written by [Robert Mosolgo](https://github.com/rmosolgo/).
+In addition, we have a subscription to [GraphQL Pro](https://graphql.pro/). For
+details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).
+
 <!-- vale gitlab.Spelling = YES -->
-In addition, we have a subscription to [GraphQL Pro](https://graphql.pro/). For details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).
 
 All GraphQL queries are directed to a single endpoint
 ([`app/controllers/graphql_controller.rb#execute`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app%2Fcontrollers%2Fgraphql_controller.rb)),

doc/development/documentation/testing.md

@@ -306,11 +306,14 @@ To configure Vale in your editor, install one of the following as appropriate:
 
   In the extension's settings:
 
+  <!-- vale gitlab.Spelling = NO -->
+
   - Select the **Use CLI** checkbox.
-  - In the <!-- vale gitlab.Spelling = NO --> **Config** setting, enter an absolute
+  - In the  **Config** setting, enter an absolute
     path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini)
     in one of the cloned GitLab repositories on your computer.
-    <!-- vale gitlab.Spelling = YES -->
+
+  <!-- vale gitlab.Spelling = YES -->
 
   - In the **Path** setting, enter the absolute path to the Vale binary. In most
     cases, `vale` should work. To find the location, run `which vale` in a terminal.

doc/development/fe_guide/index.md

@@ -12,9 +12,13 @@ across the GitLab frontend team.
 ## Overview
 
 GitLab is built on top of [Ruby on Rails](https://rubyonrails.org). It uses [Haml](https://haml.info/) and a JavaScript-based frontend with [Vue.js](https://vuejs.org).
+
 <!-- vale gitlab.Spelling = NO -->
+
 Be wary of [the limitations that come with using Hamlit](https://github.com/k0kubun/hamlit/blob/master/REFERENCE.md#limitations).
+
 <!-- vale gitlab.Spelling = YES -->
+
 We also use [SCSS](https://sass-lang.com) and plain JavaScript with
 modern ECMAScript standards supported through [Babel](https://babeljs.io/) and ES module support through [webpack](https://webpack.js.org/).
 

doc/development/fe_guide/performance.md

@@ -212,6 +212,8 @@ When writing code for real-time features we have to keep a couple of things in m
 Thus, we must strike a balance between sending requests and the feeling of real-time.
 Use the following rules when creating real-time solutions.
 
+<!-- vale gitlab.Spelling = NO -->
+
 1. The server tells you how much to poll by sending `Poll-Interval` in the header.
    Use that as your polling interval. This enables system administrators to change the
    [polling rate](../../administration/polling.md).
@@ -219,11 +221,13 @@ Use the following rules when creating real-time solutions.
 1. A response with HTTP status different from 2XX should disable polling as well.
 1. Use a common library for polling.
 1. Poll on active tabs only. Please use [Visibility](https://github.com/ai/visibilityjs).
-1. Use regular polling intervals, do not use <!-- vale gitlab.Spelling = NO --> backoff polling <!-- vale gitlab.Spelling = YES --> or jitter, as the interval is
+1. Use regular polling intervals, do not use backoff polling or jitter, as the interval is
    controlled by the server.
 1. The backend code is likely to be using ETags. You do not and should not check for status
    `304 Not Modified`. The browser transforms it for you.
 
+<!-- vale gitlab.Spelling = YES -->
+
 ### Lazy Loading Images
 
 To improve the time to first render we are using lazy loading for images. This works by setting

doc/development/fe_guide/style/scss.md

@@ -21,8 +21,11 @@ In order to reduce the generation of more CSS as our site grows, prefer the use
 #### Where are utility classes defined?
 
 Prefer the use of [utility classes defined in GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/main/doc/css.md#utilities).
+
 <!-- vale gitlab.Spelling = NO -->
+
 An easy list of classes can also be [seen on Unpkg](https://unpkg.com/browse/@gitlab/ui/src/scss/utilities.scss).
+
 <!-- vale gitlab.Spelling = YES -->
 
 Classes in [`utilities.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/utilities.scss) and [`common.scss`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/stylesheets/framework/common.scss) are being deprecated.

doc/development/gitaly.md

@@ -12,12 +12,16 @@ Workhorse and GitLab Shell.
 
 ## Deep Dive
 
-In May 2019, <!-- vale gitlab.Spelling = NO --> Bob Van Landuyt <!-- vale gitlab.Spelling = YES -->
+<!-- vale gitlab.Spelling = NO -->
+
+In May 2019, Bob Van Landuyt
 hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
 on the [Gitaly project](https://gitlab.com/gitlab-org/gitaly). It included how to contribute to it as a
 Ruby developer, and shared domain-specific knowledge with anyone who may work in this part of the
 codebase in the future.
 
+<!-- vale gitlab.Spelling = YES -->
+
 You can find the <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [recording on YouTube](https://www.youtube.com/watch?v=BmlEWFS8ORo), and the slides
 on [Google Slides](https://docs.google.com/presentation/d/1VgRbiYih9ODhcPnL8dS0W98EwFYpJ7GXMPpX-1TM6YE/edit)
 and in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/a4fdb1026278bda5c1c5bb574379cf80/Create_Deep_Dive__Gitaly_for_Create_Ruby_Devs.pdf).

doc/development/i18n/proofreader.md

@@ -12,6 +12,7 @@ are very appreciative of the work done by translators and proofreaders!
 ## Proofreaders
 
 <!-- vale gitlab.Spelling = NO -->
+
 - Albanian
   - Proofreaders needed.
 - Amharic
@@ -123,6 +124,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Andrew Vityuk - [GitLab](https://gitlab.com/3_1_3_u), [CrowdIn](https://crowdin.com/profile/andruwa13)
 - Welsh
   - Delyth Prys - [GitLab](https://gitlab.com/Delyth), [CrowdIn](https://crowdin.com/profile/DelythPrys)
+
 <!-- vale gitlab.Spelling = YES -->
 
 ## Become a proofreader

doc/development/i18n/translation.md

@@ -81,8 +81,10 @@ ethnicity. In languages that distinguish between a male and female form, use bot
 neutral formulation.
 
 <!-- vale gitlab.Spelling = NO -->
+
 For example, in German, the word _user_ can be translated into _Benutzer_ (male) or _Benutzerin_
 (female). Therefore, _create a new user_ translates to _Benutzer(in) anlegen_.
+
 <!-- vale gitlab.Spelling = YES -->
 
 ### Updating the glossary
@@ -93,7 +95,9 @@ To propose additions to the glossary, please
 ## French translation guidelines
 
 <!-- vale gitlab.Spelling = NO -->
+
 In French, the _écriture inclusive_ is now over (see on [Legifrance](https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000036068906/)).
 To include both genders, write _Utilisateurs et utilisatrices_ instead of _Utilisateur·rice·s_. If
 there is not enough space, use the male gender alone.
+
 <!-- vale gitlab.Spelling = YES -->

doc/development/integrations/jira_connect.md

@@ -19,11 +19,13 @@ The following are required to install and test the app:
   - [GDK with Gitpod](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/gitpod.md)
     documentation.
 
-  You **must not** use tunneling tools such as
-  <!-- vale gitlab.Spelling = NO --> Serveo <!-- vale gitlab.Spelling = YES -->
-  or `ngrok`. These are
+  <!-- vale gitlab.Spelling = NO -->
+
+  You **must not** use tunneling tools such as Serveo or `ngrok`. These are
   security risks, and must not be run on developer laptops.
 
+  <!-- vale gitlab.Spelling = YES -->
+
   Jira requires all connections to the app host to be over SSL. If you set up
   your own environment, remember to enable SSL and an appropriate certificate.
 

doc/development/pipelines.md

@@ -637,7 +637,9 @@ that is deployed in stage `review`.
 The default image is defined in [`.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab-ci.yml).
 
 <!-- vale gitlab.Spelling = NO -->
+
 It includes Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL, and Graphics Magick.
+
 <!-- vale gitlab.Spelling = YES -->
 
 The images used in our pipelines are configured in the

doc/development/projections.md

@@ -36,7 +36,9 @@ You can find a basic list of projection options in
 ## History
 
 <!-- vale gitlab.Spelling = NO -->
+
 This started as a
 [plugin for vim by tpope](https://github.com/tpope/vim-projectionist)
 It has since become editor-agnostic and ported to most modern editors.
+
 <!-- vale gitlab.Spelling = YES -->

doc/development/testing_guide/best_practices.md

@@ -996,11 +996,13 @@ describe "#==" do
 end
 ```
 
+<!-- vale gitlab.Spelling = NO -->
+
 WARNING:
-Only use simple values as input in the `where` block. Using
-<!-- vale gitlab.Spelling = NO --> procs, stateful
+Only use simple values as input in the `where` block. Using procs, stateful
 objects, FactoryBot-created objects, and similar items can lead to
 [unexpected results](https://github.com/tomykaira/rspec-parameterized/issues/8).
+
 <!-- vale gitlab.Spelling = YES -->
 
 ### Prometheus tests

doc/integration/gitpod.md

@@ -52,7 +52,7 @@ For GitLab self-managed instances, a GitLab administrator needs to:
    1. Add your Gitpod instance URL (for example, `https://gitpod.example.com`).
    1. Select the **Save changes** button.
 
-Your users then need to [enable it for themselves](#enable-gitpod-in-your-user-settings).
+Your users can then [enable it for themselves](#enable-gitpod-in-your-user-settings).
 
 ## Launch Gitpod in GitLab
 

doc/topics/autodevops/stages.md

@@ -107,12 +107,14 @@ Check the [currently supported languages](#currently-supported-languages).
 Auto Test uses tests you already have in your application. If there are no
 tests, it's up to you to add them.
 
+<!-- vale gitlab.Spelling = NO -->
+
 NOTE:
 Not all buildpacks supported by [Auto Build](#auto-build) are supported by Auto Test.
 Auto Test uses [Herokuish](https://gitlab.com/gitlab-org/gitlab/-/issues/212689), *not*
 Cloud Native Buildpacks, and only buildpacks that implement the
-<!-- vale gitlab.Spelling = NO -->
 [Testpack API](https://devcenter.heroku.com/articles/testpack-api) are supported.
+
 <!-- vale gitlab.Spelling = YES -->
 
 ### Currently supported languages

doc/topics/git/git_rebase.md

@@ -177,7 +177,9 @@ For example, if you're using [Vim](https://www.vim.org/) as the text editor in
 a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
 (join them into one):
 
-1. Press <!-- vale gitlab.FirstPerson = NO --> <kbd>i</kbd> <!-- vale gitlab.FirstPerson = YES -->
+<!-- vale gitlab.FirstPerson = NO -->
+
+1. Press <kbd>i</kbd>
    on your keyboard to switch to Vim's editing mode.
 1. Navigate with your keyboard arrows to edit the **second** commit keyword
    from `pick` to `squash` or `fixup` (or `s` or `f`). Do the same to the **third** commit.
@@ -194,6 +196,8 @@ a macOS's `ZSH` shell, and you want to `squash` or `fixup` all the three commits
    push your changes normally. If you had pushed these commits already,
    [force-push](#force-push) instead.
 
+<!-- vale gitlab.FirstPerson = YES -->
+
 Note that the steps for editing through the command line can be slightly
 different depending on your operating system and the shell you're using.
 

doc/topics/git/lfs/index.md

@@ -271,7 +271,11 @@ If you are storing LFS files outside of GitLab you can disable LFS on the projec
 
 It is possible to host LFS objects externally by setting a custom LFS URL with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
 
-You might choose to do this if you are using an appliance like a <!-- vale gitlab.Spelling = NO --> Sonatype Nexus <!-- vale gitlab.Spelling = YES --> to store LFS data. If you choose to use an external LFS store,
+<!-- vale gitlab.Spelling = NO -->
+
+You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store,
 GitLab can't verify LFS objects. Pushes then fail if you have GitLab LFS support enabled.
 
+<!-- vale gitlab.Spelling = YES -->
+
 To stop push failure, LFS support can be disabled in the [Project settings](../../../user/project/settings/index.md), which also disables GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).

doc/update/mysql_to_postgresql.md

@@ -52,7 +52,7 @@ For other distributions, follow the instructions in PostgreSQL's
 and then install `pgloader`.
 
 If you are migrating to a Docker based installation, you must install
-pgLoader within the container as it is not included in the container image.
+pgLoader in the container as it is not included in the container image.
 
 1. Start a shell session in the context of the running container:
 
@@ -70,7 +70,7 @@ pgLoader within the container as it is not included in the container image.
 ## Omnibus GitLab installations
 
 For [Omnibus GitLab packages](https://about.gitlab.com/install/), you first
-need to enable the bundled PostgreSQL:
+enable the bundled PostgreSQL:
 
 1. Stop GitLab:
 
@@ -283,7 +283,7 @@ Sometimes, you might encounter some errors during or after the migration.
 
 ### Database error permission denied
 
-The PostgreSQL user that you use for the migration MUST have **superuser** privileges.
+The PostgreSQL user that you use for the migration **must** have **superuser** privileges.
 Otherwise, you may see a similar message to the following:
 
 ```plaintext
@@ -295,7 +295,7 @@ debugger invoked on a CL-POSTGRES-ERROR:INSUFFICIENT-PRIVILEGE in thread
     QUERY: ALTER TABLE approver_groups DISABLE TRIGGER ALL;
 ```
 
-### Experiencing 500 errors after the migration
+### 500 errors after the migration
 
 If you experience 500 errors after the migration, try to clear the cache:
 

doc/update/restore_after_failure.md

@@ -13,7 +13,7 @@ However, it's important to know how to recover when problems do arise.
 
 In some cases after a failed upgrade, the fastest solution is to roll back to
 the previous version you were using. We recommend this path because the failed
-upgrade will likely have made database changes that can not be readily reverted.
+upgrade might have made database changes that cannot be readily reverted.
 
 First, roll back the code or package. For source installations this involves
 checking out the older version (branch or tag). For Omnibus installations this
@@ -33,7 +33,7 @@ older backup it can lead to migration failures on future upgrades.
 
 Starting in GitLab 8.6 we drop all tables prior to importing the backup to
 prevent this problem. If you've restored a backup to a version prior to 8.6 you
-may need to manually correct the problem next time you upgrade.
+may have to manually correct the problem next time you upgrade.
 
 Example error:
 
@@ -49,8 +49,8 @@ PG::DuplicateTable: ERROR:  relation "lfs_objects" already exists
 Copy the version from the error. In this case the version number is
 `20151103134857`.
 
->**WARNING:** Use the following steps only if you are certain this is what you
-need to do.
+WARNING:
+Use the following steps only if you are certain you must do them.
 
 ### GitLab 8.6+
 
@@ -65,9 +65,8 @@ sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857
 sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
 ```
 
-Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You might need to repeat this process several times until all failed
-migrations are marked complete.
+After the migration is successfully marked, run the Rake `db:migrate` task again.
+Repeat this process until all failed migrations are complete.
 
 ### GitLab < 8.6
 
@@ -86,6 +85,5 @@ ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) V
 exit
 ```
 
-Once the migration is successfully marked, run the Rake `db:migrate` task again.
-You might need to repeat this process several times until all failed
-migrations are marked complete.
+After the migration is successfully marked, run the Rake `db:migrate` task again.
+Repeat this process until all failed migrations are complete.

doc/update/upgrading_from_source.md

@@ -12,12 +12,10 @@ Users wishing to upgrade to 12.0.0 must take some extra steps. See the
 version specific upgrade instructions for 12.0.0 for more details.
 
 Make sure you view this update guide from the branch (version) of GitLab you
-would like to install (e.g., `11.8`. You can select the version in the version
-dropdown at the top left corner of GitLab (below the menu bar).
+would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown at the top right corner of GitLab documentation page.
 
-In all examples, replace `BRANCH` with the branch for the version you upgrading
-to (e.g. `11-8-stable` for `11.8`), and replace `PREVIOUS_BRANCH` with the
-branch for the version you are upgrading from (e.g. `11-7-stable` for `11.7`).
+In each of the following examples, replace `BRANCH` with the branch of the version you upgrading to (for example, `11-8-stable` for `11.8`). Replace `PREVIOUS_BRANCH` with the
+branch for the version you are upgrading from (for example, `11-7-stable` for `11.7`).
 
 If the highest number stable branch is unclear please check the
 [GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation
@@ -29,7 +27,7 @@ the [Upgrading from CE to EE](upgrading_from_ce_to_ee.md) documentation.
 ## Upgrading to a new major version
 
 Major versions are reserved for backwards incompatible changes. We recommend that
-you first upgrade to the latest available minor version within your major version.
+you first upgrade to the latest available minor version of your current major version.
 Please follow the [Upgrade Recommendations](../policy/maintenance.md#upgrade-recommendations)
 to identify the ideal upgrade path.
 
@@ -152,7 +150,7 @@ WARNING:
 From GitLab 14.0, you must use at least PostgreSQL 12.
 
 The latest version of GitLab might depend on a more recent PostgreSQL version
-than what you're currently running. You may also need to enable some
+than what you are running. You may also have to enable some
 extensions. For more information, see the
 [PostgreSQL requirements](../install/requirements.md#postgresql-requirements)
 
@@ -212,9 +210,9 @@ git diff origin/PREVIOUS_BRANCH:lib/support/nginx/gitlab-ssl origin/BRANCH:lib/s
 git diff origin/PREVIOUS_BRANCH:lib/support/nginx/gitlab origin/BRANCH:lib/support/nginx/gitlab
 ```
 
-If you are using Strict-Transport-Security in your installation to continue
-using it you must enable it in your NGINX configuration as GitLab application no
-longer handles setting it.
+If you are using Strict-Transport-Security in your installation, you must enable it in your
+NGINX configuration to continue using it. This is because the GitLab application no longer
+sets it.
 
 If you are using Apache instead of NGINX see the updated [Apache templates](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
 Also note that because Apache does not support upstreams behind Unix sockets you
@@ -391,11 +389,11 @@ cp config/initializers/rack_attack.rb config/initializers/rack_attack_backup.rb
 
 ### 1. Revert the code to the previous version
 
-To revert to a previous version, you need to follow the upgrading guides
+To revert to a previous version, you must follow the upgrading guides
 for the previous version.
 
 For example, if you have upgraded to GitLab 12.6 and want to revert back to
-12.5, you need to follow the guides for upgrading from 12.4 to 12.5. You can
+12.5, follow the guides for upgrading from 12.4 to 12.5. You can
 use the version dropdown at the top of the page to select the right version.
 
 When reverting, you should **not** follow the database migration guides, as the

doc/user/application_security/dast/index.md

@@ -1048,7 +1048,12 @@ When an API site type is selected, a [host override](#host-override) is used to
 
 #### Site profile validation
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233020) in GitLab 13.8.
+> - Site profile validation [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233020) in GitLab 13.8.
+> - Meta tag validation [enabled on GitLab.com](https://gitlab.com/issue/etc) in GitLab 14.2 and is ready for production use.
+> - Meta tag validation [enabled with `dast_meta_tag_validation flag` flag](https://gitlab.com/issue/etc) for self-managed GitLab in GitLab 14.2 and is ready for production use.
+
+FLAG:
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the `dast_meta_tag_validation` flag](../../../administration/feature_flags.md). On GitLab.com, this feature is available but can be configured by GitLab.com administrators only.
 
 Site profile validation reduces the risk of running an active scan against the wrong website. A site
 must be validated before an active scan can run against it. The site validation methods are as
@@ -1060,8 +1065,11 @@ follows:
 - _Header validation_ requires the header `Gitlab-On-Demand-DAST` be added to the target site,
   with a value unique to the project. The validation process checks that the header is present, and
   checks its value.
+- _Meta tag validation_ requires the meta tag named `gitlab-dast-validation` be added to the target site,
+  with a value unique to the project. Make sure it's added to the `<head>` section of the page. The validation process checks that the meta tag is present, and
+  checks its value.
 
-Both methods are equivalent in functionality. Use whichever is feasible.
+All these methods are equivalent in functionality. Use whichever is feasible.
 
 In [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/324990), site profile
 validation happens in a CI job using the [GitLab Runner](../../../ci/runners/index.md).
@@ -1129,6 +1137,11 @@ To validate a site profile:
       1. Edit the header of the site to validate, and paste the clipboard content.
       1. Select the input field in **Step 3** and enter the location of the header.
       1. Select **Validate**.
+   1. For **Meta tag validation**:
+      1. Select the clipboard icon in **Step 2**.
+      1. Edit the content of the site to validate, and paste the clipboard content.
+      1. Select the input field in **Step 3** and enter the location of the meta tag.
+      1. Select **Validate**.
 
 The site is validated and an active scan can run against it.
 

doc/user/project/highlighting.md

@@ -14,18 +14,23 @@ The [Web IDE](web_ide/index.md) and [Snippets](../snippets.md) use [Monaco Edito
 for text editing, which internally uses the [Monarch](https://microsoft.github.io/monaco-editor/monarch.html)
 library for syntax highlighting.
 
+<!-- vale gitlab.Spelling = NO -->
+
 If GitLab is guessing wrong, you can override its choice of language using the
-`gitlab-language` attribute in `.gitattributes`. For example, if you are working in a
-<!-- vale gitlab.Spelling = NO --> Prolog <!-- vale gitlab.Spelling = YES -->
+`gitlab-language` attribute in `.gitattributes`. For example, if you are working in a Prolog
 project and using the `.pl` file extension (which would normally be highlighted as Perl),
 you can add the following to your `.gitattributes` file:
 
+<!-- vale gitlab.Spelling = YES -->
+
 ``` conf
 *.pl gitlab-language=prolog
 ```
 
 <!-- vale gitlab.Spelling = NO -->
+
 When you check in and push that change, all `*.pl` files in your project are highlighted as Prolog.
+
 <!-- vale gitlab.Spelling = YES -->
 
 The paths here are Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used Ruby syntax, all you need is:

doc/user/project/issues/csv_export.md

@@ -18,9 +18,12 @@ file, which stores tabular data in plain text.
 > _CSVs are a handy way of getting data from one program to another where one
 program cannot read the other ones normal output._ [Ref](https://www.quora.com/What-is-a-CSV-file-and-its-uses)
 
+<!-- vale gitlab.Spelling = NO -->
+
 CSV files can be used with any plotter or spreadsheet-based program, such as
-Microsoft Excel, Open Office <!-- vale gitlab.Spelling = NO --> Calc, <!-- vale gitlab.Spelling = NO -->,
-or Google Sheets.
+Microsoft Excel, Open Office Calc, or Google Sheets.
+
+<!-- vale gitlab.Spelling = YES -->
 
 Here are some of the uses of exporting issues as CSV files:
 

doc/user/project/merge_requests/fail_fast_testing.md

@@ -19,7 +19,7 @@ that it believes to be relevant to the input files.
 
 `tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is
 configured to run when changes to Ruby files are detected. By default, it runs in
-the [`.pre` stage](../../../ci/yaml/index.md#pre-and-post) of a GitLab CI/CD pipeline,
+the [`.pre` stage](../../../ci/yaml/index.md#stage-pre) of a GitLab CI/CD pipeline,
 before all other stages.
 
 ## Example use case

doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md

@@ -32,8 +32,11 @@ nor credit card transactions, then why do we need secure connections?
 Back in the 1990s, where HTTPS came out, [SSL](https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0) was considered a "special"
 security measure, necessary just for big companies like banks and shopping sites
 with financial transactions.
+
 <!-- vale gitlab.Spelling = NO -->
+
 Now we have a different picture. [According to Josh Aas](https://letsencrypt.org/2015/10/29/phishing-and-malware.html), Executive Director at [ISRG](https://en.wikipedia.org/wiki/Internet_Security_Research_Group):
+
 <!-- vale gitlab.rulename = YES -->
 
 > _We've since come to realize that HTTPS is important for almost all websites. It's important for any website that allows people to log in with a password, any website that [tracks its users](https://www.washingtonpost.com/news/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/) in any way, any website that [doesn't want its content altered](https://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/), and for any site that offers content people might not want others to know they are consuming. We've also learned that any site not secured by HTTPS [can be used to attack other sites](https://krebsonsecurity.com/2015/04/dont-be-fodder-for-chinas-great-cannon/)._

doc/user/project/requirements/index.md

@@ -295,8 +295,10 @@ To export requirements:
 ### Exported CSV file format
 
 <!-- vale gitlab.Spelling = NO -->
+
 You can preview the exported CSV file in a spreadsheet editor, such as Microsoft Excel,
 OpenOffice Calc, or Google Sheets.
+
 <!-- vale gitlab.Spelling = YES -->
 
 The exported CSV file contains the following headers:

lib/gitlab/background_migration/create_security_setting.rb

@@ -0,0 +1,14 @@
+# frozen_string_literal: true
+
+module Gitlab
+  module BackgroundMigration
+    # This class doesn't create SecuritySetting
+    # as this feature exists only in EE
+    class CreateSecuritySetting
+      def perform(_from_id, _to_id)
+      end
+    end
+  end
+end
+
+Gitlab::BackgroundMigration::CreateSecuritySetting.prepend_mod_with('Gitlab::BackgroundMigration::CreateSecuritySetting')

lib/gitlab/import_export/json/streaming_serializer.rb

@@ -31,10 +31,12 @@ module Gitlab
         end
 
         def execute
-          serialize_root
+          read_from_replica_if_available do
+            serialize_root
 
-          includes.each do |relation_definition|
-            serialize_relation(relation_definition)
+            includes.each do |relation_definition|
+              serialize_relation(relation_definition)
+            end
           end
         end
 
@@ -166,6 +168,13 @@ module Gitlab
             )
           ])
         end
+
+        def read_from_replica_if_available(&block)
+          return yield unless ::Feature.enabled?(:load_balancing_for_export_workers, type: :development, default_enabled: :yaml)
+          return yield unless ::Gitlab::Database::LoadBalancing.enable?
+
+          ::Gitlab::Database::LoadBalancing::Session.current.use_replicas_for_read_queries(&block)
+        end
       end
     end
   end

spec/lib/gitlab/import_export/json/streaming_serializer_spec.rb

@@ -156,6 +156,41 @@ RSpec.describe Gitlab::ImportExport::Json::StreamingSerializer do
         subject.execute
       end
     end
+
+    describe 'load balancing' do
+      context 'when feature flag load_balancing_for_export_workers is enabled' do
+        before do
+          stub_feature_flags(load_balancing_for_export_workers: true)
+        end
+
+        context 'when enabled', :db_load_balancing do
+          it 'reads from replica' do
+            expect(Gitlab::Database::LoadBalancing::Session.current).to receive(:use_replicas_for_read_queries).and_call_original
+
+            subject.execute
+          end
+        end
+
+        context 'when disabled' do
+          it 'reads from primary' do
+            allow(Gitlab::Database::LoadBalancing).to receive(:enable?).and_return(false)
+            expect(Gitlab::Database::LoadBalancing::Session.current).not_to receive(:use_replicas_for_read_queries)
+
+            subject.execute
+          end
+        end
+      end
+
+      context 'when feature flag load_balancing_for_export_workers is disabled' do
+        it 'reads from primary' do
+          stub_feature_flags(load_balancing_for_export_workers: false)
+
+          expect(Gitlab::Database::LoadBalancing::Session.current).not_to receive(:use_replicas_for_read_queries)
+
+          subject.execute
+        end
+      end
+    end
   end
 
   describe '.batch_size' do

spec/migrations/schedule_security_setting_creation_spec.rb

@@ -0,0 +1,58 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+require_migration!
+
+RSpec.describe ScheduleSecuritySettingCreation, :sidekiq do
+  describe '#up' do
+    let(:projects) { table(:projects) }
+    let(:namespaces) { table(:namespaces) }
+
+    context 'for EE version' do
+      before do
+        stub_const("#{described_class.name}::BATCH_SIZE", 2)
+        allow(Gitlab).to receive(:ee?).and_return(true)
+      end
+
+      it 'schedules background migration job' do
+        namespace = namespaces.create!(name: 'test', path: 'test')
+        projects.create!(id: 12, namespace_id: namespace.id, name: 'red', path: 'red')
+        projects.create!(id: 13, namespace_id: namespace.id, name: 'green', path: 'green')
+        projects.create!(id: 14, namespace_id: namespace.id, name: 'blue', path: 'blue')
+
+        Sidekiq::Testing.fake! do
+          freeze_time do
+            migrate!
+
+            expect(described_class::MIGRATION)
+              .to be_scheduled_delayed_migration(5.minutes, 12, 13)
+
+            expect(described_class::MIGRATION)
+              .to be_scheduled_delayed_migration(10.minutes, 14, 14)
+
+            expect(BackgroundMigrationWorker.jobs.size).to eq(2)
+          end
+        end
+      end
+    end
+
+    context 'for FOSS version' do
+      before do
+        allow(Gitlab).to receive(:ee?).and_return(false)
+      end
+
+      it 'does not schedule any jobs' do
+        namespace = namespaces.create!(name: 'test', path: 'test')
+        projects.create!(id: 12, namespace_id: namespace.id, name: 'red', path: 'red')
+
+        Sidekiq::Testing.fake! do
+          freeze_time do
+            migrate!
+
+            expect(BackgroundMigrationWorker.jobs.size).to eq(0)
+          end
+        end
+      end
+    end
+  end
+end

spec/models/concerns/strip_attribute_spec.rb

@@ -5,12 +5,12 @@ require 'spec_helper'
 RSpec.describe StripAttribute do
   let(:milestone) { create(:milestone) }
 
-  describe ".strip_attributes" do
-    it { expect(Milestone).to respond_to(:strip_attributes) }
+  describe ".strip_attributes!" do
+    it { expect(Milestone).to respond_to(:strip_attributes!) }
     it { expect(Milestone.strip_attrs).to include(:title) }
   end
 
-  describe "#strip_attributes" do
+  describe "#strip_attributes!" do
     before do
       milestone.title = '    8.3   '
       milestone.valid?

spec/support/database/prevent_cross_database_modification.rb

@@ -6,17 +6,15 @@ module Database
 
     module GitlabDatabaseMixin
       def allow_cross_database_modification_within_transaction(url:)
-        return yield unless Thread.current[:transaction_tracker]
-
         cross_database_context = Database::PreventCrossDatabaseModification.cross_database_context
-        return yield unless cross_database_context[:enabled]
+        return yield unless cross_database_context && cross_database_context[:enabled]
 
         transaction_tracker_enabled_was = cross_database_context[:enabled]
         cross_database_context[:enabled] = false
 
         yield
       ensure
-        cross_database_context[:enabled] = transaction_tracker_enabled_was if Thread.current[:transaction_tracker]
+        cross_database_context[:enabled] = transaction_tracker_enabled_was if cross_database_context
       end
     end
 
@@ -41,7 +39,7 @@ module Database
     end
 
     def self.cross_database_context
-      Thread.current[:transaction_tracker] ||= initial_data
+      Thread.current[:transaction_tracker]
     end
 
     def self.reset_cross_database_context!
@@ -82,18 +80,9 @@ module Database
 
       cross_database_context[:modified_tables_by_db][database].merge(tables)
 
-      ci_table_referenced = false
-      main_table_referenced = false
       all_tables = cross_database_context[:modified_tables_by_db].values.map(&:to_a).flatten
-      all_tables.each do |table|
-        if Database::CiTables.include?(table)
-          ci_table_referenced = true
-        else
-          main_table_referenced = true
-        end
-      end
 
-      if ci_table_referenced && main_table_referenced
+      unless PreventCrossJoins.only_ci_or_only_main?(all_tables)
         raise Database::PreventCrossDatabaseModification::CrossDatabaseModificationAcrossUnsupportedTablesError,
           "Cross-database data modification queries (CI and Main) were detected within " \
           "a transaction '#{all_tables.join(", ")}' discovered"