From e8d2c2579383897a1dd7f9debd359abe8ae8373d Mon Sep 17 00:00:00 2001
From: GitLab Bot <gitlab-bot@gitlab.com>
Date: Tue, 20 Jul 2021 09:55:51 +0000
Subject: Add latest changes from gitlab-org/gitlab@14-1-stable-ee

---
 .gitlab/issue_templates/Deprecations.md            |  50 ++++++
 .gitlab/issue_templates/Design Sprint.md           |   1 +
 .gitlab/issue_templates/Feature Flag Roll Out.md   |  11 +-
 .../issue_templates/Feature Proposal - basic.md    |   5 +-
 .../Geo Replicate a new Git repository type.md     | 174 +++++++++++++-------
 .../Geo Replicate a new blob type.md               | 176 ++++++++++++++-------
 .../issue_templates/Security developer workflow.md |   5 +-
 .gitlab/issue_templates/Snowplow event tracking.md |   2 +-
 8 files changed, 306 insertions(+), 118 deletions(-)
 create mode 100644 .gitlab/issue_templates/Deprecations.md

(limited to '.gitlab/issue_templates')

diff --git a/.gitlab/issue_templates/Deprecations.md b/.gitlab/issue_templates/Deprecations.md
new file mode 100644
index 00000000000..ff51699c6be
--- /dev/null
+++ b/.gitlab/issue_templates/Deprecations.md
@@ -0,0 +1,50 @@
+<!-- Use this template as a starting point for deprecations. -->
+
+### Deprecation Summary
+
+<!--
+This should contain a brief description of the feature or functionality that is deprecated. The description should clearly state the potential impact of the deprecation to end users.
+
+It is recommended that you link to the documentation.
+
+The description of the deprecation should state what actions the user should take to rectify the behavior. If the deprecation is scheduled for an upcoming release, the content should remain in the deprecations documentation page until it has been completed. For example, if a deprecation is announced in 14.9 and scheduled to be completed in 15.0, the same content would be included in the documentation for 14.9, 14.10, and 15.0.
+-->
+
+### Breaking Change
+
+<!-- Is this a breaking change or not? If so, please add instructions for how users can update their workflow. -->
+### Affected Topology
+
+<!--
+Who is affected by this deprecation, Self-managed users, SaaS users, or both? This is especially important when nearing the annual major release where breaking changes and removals are typically introduced. These changes might be seen on GitLab.com before the official release date.
+-->
+
+### Affected Tier
+
+<!--
+Which tier is this feature available in?
+
+* Free
+* Premium
+* Ultimate
+-->
+
+### Checklist
+
+- [ ] @mention your stage's stable counterparts on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
+  - To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/)
+       - If there is no stable counterpart listed for Sales/CS please mention `@timtams`
+       - If there is no stable counterpart listed for Support please @mention `@gitlab-com/support/managers`
+       - If there is no stable counterpart listed for Marketing please mention `@williamchia`
+
+- [ ] @mention your GPM so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
+
+### Deprecation Milestone
+
+<!-- In which milestone will this deprecation happen? -->
+
+### Links
+
+<!--
+Add links to any relevant documentation or code that will provide additional details or clarity regarding the planned change. Also, include a link to the removal issue if relevant.
+-->
diff --git a/.gitlab/issue_templates/Design Sprint.md b/.gitlab/issue_templates/Design Sprint.md
index 787c4469b88..06ef7dc9abc 100644
--- a/.gitlab/issue_templates/Design Sprint.md	
+++ b/.gitlab/issue_templates/Design Sprint.md	
@@ -98,6 +98,7 @@ If you enjoy taking notes using post-it notes make sure you have available some
 
 - [ ] Finalise participant list - `decider` and `facilitator`
 - [ ] Create [participation form](https://docs.google.com/forms/d/e/1FAIpQLSc0_BNltvRW8yXXaJd8sIKzgDmrSGqILMfkoCJrAj6sFcsMcg/viewform?usp=sf_link) and send to participants (**deadline**: [date]) - `facilitator` 
+- [ ] Create a dedicated Slack channel and add participants - `facilitator`
 - [ ] Promote this issue to an epic - `facilitator`
 - [ ] Create issues under the epic for the pre-workshop tasks: Expert interviews ([example](https://gitlab.com/groups/gitlab-org/configure/-/epics/3#note_332412524)), Lightning walkthroughs and How might we.. notetaking assignment ([example](https://gitlab.com/gitlab-org/configure/general/-/issues/52)), Voting How might we... notes assignment ([example](https://gitlab.com/gitlab-org/configure/general/-/issues/54)) - `facilitator` 
 - [ ] Create sync meetings in calendar and invite all participants (**deadline**: [date]) - `decider` or `facilitator` 
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index 424b752d1b4..ec6e5dfd7d4 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md	
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md	
@@ -78,6 +78,7 @@ Are there any other stages or teams involved that need to be kept in the loop?
   If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
 - [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default)).
 - [ ] Announce on [the feature issue](ISSUE LINK) an estimated time this will be enabled on GitLab.com.
+- [ ] If the feature might impact the user experience, notify `#support_gitlab-com` and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
 - [ ] If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), enable it on GitLab.com for [testing groups/projects](#testing-groupsprojectsusers).
     - [ ] `/chatops run feature set --<actor-type>=<actor> <feature-flag-name> true`
 - [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
@@ -92,8 +93,6 @@ Are there any other stages or teams involved that need to be kept in the loop?
   - Enable the feature globally on production environment.
     - [ ] `/chatops run feature set <feature-flag-name> true`
 - [ ] Announce on [the feature issue](ISSUE LINK) that the feature has been globally enabled.
-- [ ] Cross-post chatops slack command to `#support_gitlab-com`.
-  ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)) and in your team channel
 - [ ] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).
 
 ### (Optional) Release the feature with the feature flag
@@ -105,10 +104,10 @@ To do so, follow these steps:
 - [ ] Create a merge request with the following changes. Ask for review and merge it.
     - [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
     - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
-- [ ] Ensure that the above MR has been deployed to both production and canary.
+- [ ] Ensure that the default-enabling MR has been deployed to both production and canary.
       If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
       the feature can be officially announced in a release blog post.
-    - [ ] `/chatops run auto_deploy status <merge-commit>`
+    - [ ] `/chatops run auto_deploy status <merge-commit-of-default-enabling-mr>`
 - [ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
 - [ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature).
 - [ ] (Optional) You can create a separate issue for scheduling the steps below to [Release the feature](#release-the-feature).
@@ -136,10 +135,10 @@ codebase.
     - [ ] Remove all references to the feature flag from the codebase.
     - [ ] Remove the YAML definitions for the feature from the repository.
     - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
-- [ ] Ensure that the above MR has been deployed to both production and canary.
+- [ ] Ensure that the cleanup MR has been deployed to both production and canary.
       If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
       the feature can be officially announced in a release blog post.
-    - [ ] `/chatops run auto_deploy status <merge-commit>`
+    - [ ] `/chatops run auto_deploy status <merge-commit-of-cleanup-mr>`
 - [ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
 - [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel:
     - [ ] `/chatops run feature delete <feature-flag-name> --dev`
diff --git a/.gitlab/issue_templates/Feature Proposal - basic.md b/.gitlab/issue_templates/Feature Proposal - basic.md
index 099243c05ca..0c05b7a0165 100644
--- a/.gitlab/issue_templates/Feature Proposal - basic.md	
+++ b/.gitlab/issue_templates/Feature Proposal - basic.md	
@@ -5,7 +5,6 @@
 <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
 
 <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
-
-/label ~"group::" ~"section::"  ~"Category::" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate" 
-
 -->
+
+/label ~feature::addition ~"group::" ~"section::" ~"Category:" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"
diff --git a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
index be6fef40f3a..560b1722348 100644
--- a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md	
+++ b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md	
@@ -1,6 +1,6 @@
 <!--
 
-This template is based on a model named `CoolWidget`. 
+This template is based on a model named `CoolWidget`.
 
 To adapt this template, find and replace the following tokens:
 
@@ -34,6 +34,9 @@ There are three main sections below. It is a good idea to structure your merge r
 
 It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
 
+You can look into the following example for implementing replication/verification for a new Git repository type:
+- [Add snippet repository verification](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56596)
+
 ### Modify database schemas to prepare to add Geo support for Cool Widgets
 
 You might do this section in its own merge request, but it is not required.
@@ -342,39 +345,6 @@ That's all of the required database changes.
 
 - [ ] Implement `CoolWidget.replicables_for_current_secondary` above.
 - [ ] Ensure `CoolWidget.replicables_for_current_secondary` is well-tested. Search the codebase for `replicables_for_current_secondary` to find examples of parameterized table specs. You may need to add more `FactoryBot` traits.
-- [ ] If you are using a separate table `cool_widget_states` to track verification state on the Geo primary site, then:
-  - [ ] Do not include `::Gitlab::Geo::VerificationState` on the `CoolWidget` class.
-  - [ ] Add the following lines to the `cool_widget_state.rb` model:
-
-    ```ruby
-    class CoolWidgetState < ApplicationRecord
-      ...
-      self.primary_key = :cool_widget_id
-
-      include ::Gitlab::Geo::VerificationState
-
-      belongs_to :cool_widget, inverse_of: :cool_widget_state
-      ...
-    end
-    ```
-
-  - [ ] Add the following lines to the `cool_widget` model:
-
-    ```ruby
-    class CoolWidget < ApplicationRecord
-      ...
-      has_one :cool_widget_state, inverse_of: :cool_widget
-
-      delegate :verification_retry_at, :verification_retry_at=,
-              :verified_at, :verified_at=,
-              :verification_checksum, :verification_checksum=,
-              :verification_failure, :verification_failure=,
-              :verification_retry_count, :verification_retry_count=,
-              to: :cool_widget_state
-      ...
-    end
-    ```
-
 - [ ] Create `ee/app/replicators/geo/cool_widget_replicator.rb`. Implement the `#repository` method which should return a `<Repository>` instance, and implement the class method `.model` to return the `CoolWidget` class:
 
   ```ruby
@@ -383,6 +353,7 @@ That's all of the required database changes.
   module Geo
     class CoolWidgetReplicator < Gitlab::Geo::Replicator
       include ::Geo::RepositoryReplicatorStrategy
+      extend ::Gitlab::Utils::Override
 
       def self.model
         ::CoolWidget
@@ -493,7 +464,7 @@ That's all of the required database changes.
 
   FactoryBot.define do
     factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
-      cool_widget
+      cool_widget # This association should have data, like a file or repository
       state { Geo::CoolWidgetRegistry.state_value(:pending) }
 
       trait :synced do
@@ -542,6 +513,119 @@ That's all of the required database changes.
   end
   ```
 
+- [ ] Add the following to `spec/factories/cool_widgets.rb`:
+
+  ```ruby
+  trait(:verification_succeeded) do
+    with_file
+    verification_checksum { 'abc' }
+    verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
+  end
+
+  trait(:verification_failed) do
+    with_file
+    verification_failure { 'Could not calculate the checksum' }
+    verification_state { CoolWidget.verification_state_value(:verification_failed) }
+  end
+  ```
+
+- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
+
+##### If you added verification state fields to a separate table (option 2 above), then you need to make additional model and factory changes
+
+If you did not add verification state fields to a separate table, `cool_widget_states`, then skip to [Step 2. Implement metrics gathering](#step-2-implement-metrics-gathering).
+
+Otherwise, you can follow [the example of Merge Request Diffs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309).
+
+- [ ] Add a `Geo::CoolWidgetState` model in `ee/app/models/ee/geo/cool_widget_state.rb`:
+
+  ``` ruby
+  module Geo
+    class CoolWidgetState < ApplicationRecord
+      self.primary_key = :cool_widget_id
+
+      belongs_to :cool_widget, inverse_of: :cool_widget_state
+    end
+  end
+  ```
+
+- [ ] Add a `factory` for `cool_widget_state`, in `ee/spec/factories/geo/cool_widget_states.rb`:
+
+  ``` ruby
+  # frozen_string_literal: true
+
+  FactoryBot.define do
+    factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
+      cool_widget
+
+      trait(:checksummed) do
+        verification_checksum { 'abc' }
+      end
+
+      trait(:checksum_failure) do
+        verification_failure { 'Could not calculate the checksum' }
+      end
+    end
+  end
+  ```
+
+- [ ] Add the following lines to the `cool_widget` model to accomplish some important tasks:
+  - Include the `::Gitlab::Geo::VerificationState` concern.
+  - Delegate verification related methods to the `cool_widget_state` model.
+  - Override some scopes to use the `cool_widget_states` table instead of the model table, for verification.
+  - Override some methods to use the `cool_widget_states` table in verification related queries.
+
+  ```ruby
+  class CoolWidget < ApplicationRecord
+    ...
+    include ::Gitlab::Geo::VerificationState
+
+    has_one :cool_widget_state, autosave: true, inverse_of: :cool_widget, class_name: 'Geo::CoolWidgetState'
+
+    delegate :verification_retry_at, :verification_retry_at=,
+             :verified_at, :verified_at=,
+             :verification_checksum, :verification_checksum=,
+             :verification_failure, :verification_failure=,
+             :verification_retry_count, :verification_retry_count=,
+             :verification_state=, :verification_state,
+             :verification_started_at=, :verification_started_at,
+             to: :cool_widget_state
+    ...
+
+    scope :with_verification_state, ->(state) { joins(:cool_widget_state).where(cool_widget_states: { verification_state: verification_state_value(state) }) }
+    scope :checksummed, -> { joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil } ) }
+    scope :not_checksummed, -> { joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil } ) }
+
+    ...
+
+    class_methods do
+      extend ::Gitlab::Utils::Override
+      ...
+      override :verification_state_table_name
+      def verification_state_table_name
+        'cool_widget_states'
+      end
+
+      override :verification_state_model_key
+      def verification_state_model_key
+        'cool_widget_id'
+      end
+
+      override :verification_arel_table
+      def verification_arel_table
+        CoolWidgetState.arel_table
+      end
+    end
+    ...
+
+    def cool_widget_state
+      super || build_cool_widget_state
+    end
+
+    ...
+  end
+  ```
+
 #### Step 2. Implement metrics gathering
 
 Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus` for display in the UI, and sent to Prometheus:
@@ -578,24 +662,6 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
   Geo::CoolWidgetReplicator | :cool_widget | :geo_cool_widget_registry
   ```
 
-- [ ] Add the following to `spec/factories/cool_widgets.rb`:
-
-  ```ruby
-  trait(:verification_succeeded) do
-    with_file
-    verification_checksum { 'abc' }
-    verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-  end
-
-  trait(:verification_failed) do
-    with_file
-    verification_failure { 'Could not calculate the checksum' }
-    verification_state { CoolWidget.verification_state_value(:verification_failed) }
-  end
-  ```
-
-- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
-
 Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
 
 #### Step 3. Implement the GraphQL API
@@ -736,6 +802,8 @@ Individual Cool Widget replication and verification data should now be available
   module Geo
     class CoolWidgetReplicator < Gitlab::Geo::Replicator
       ...
+      # REMOVE THIS LINE IF IT IS NO LONGER NEEDED
+      extend ::Gitlab::Utils::Override
 
       # REMOVE THIS METHOD
       def self.replication_enabled_by_default?
diff --git a/.gitlab/issue_templates/Geo Replicate a new blob type.md b/.gitlab/issue_templates/Geo Replicate a new blob type.md
index c7bbb6b937c..58b08f490f7 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md	
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md	
@@ -1,6 +1,6 @@
 <!--
 
-This template is based on a model named `CoolWidget`. 
+This template is based on a model named `CoolWidget`.
 
 To adapt this template, find and replace the following tokens:
 
@@ -34,6 +34,10 @@ There are three main sections below. It is a good idea to structure your merge r
 
 It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
 
+You can look into the following examples of MRs for implementing replication/verification for a new blob type:
+- [Add db changes](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60935) and [add verification for MR diffs using SSF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309)
+- [Verify Terraform state versions](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58800)
+
 ### Modify database schemas to prepare to add Geo support for Cool Widgets
 
 You might do this section in its own merge request, but it is not required.
@@ -331,39 +335,6 @@ That's all of the required database changes.
 
 - [ ] Implement `CoolWidget.replicables_for_current_secondary` above.
 - [ ] Ensure `CoolWidget.replicables_for_current_secondary` is well-tested. Search the codebase for `replicables_for_current_secondary` to find examples of parameterized table specs. You may need to add more `FactoryBot` traits.
-- [ ] If you are using a separate table `cool_widget_states` to track verification state on the Geo primary site, then:
-  - [ ] Do not include `::Gitlab::Geo::VerificationState` on the `CoolWidget` class.
-  - [ ] Add the following lines to the `cool_widget_state.rb` model:
-
-    ```ruby
-    class CoolWidgetState < ApplicationRecord
-      ...
-      self.primary_key = :cool_widget_id
-
-      include ::Gitlab::Geo::VerificationState
-
-      belongs_to :cool_widget, inverse_of: :cool_widget_state
-      ...
-    end
-    ```
-
-  - [ ] Add the following lines to the `cool_widget` model:
-
-    ```ruby
-    class CoolWidget < ApplicationRecord
-      ...
-      has_one :cool_widget_state, inverse_of: :cool_widget
-
-      delegate :verification_retry_at, :verification_retry_at=,
-              :verified_at, :verified_at=,
-              :verification_checksum, :verification_checksum=,
-              :verification_failure, :verification_failure=,
-              :verification_retry_count, :verification_retry_count=,
-              to: :cool_widget_state
-      ...
-    end
-    ```
-
 - [ ] Create `ee/app/replicators/geo/cool_widget_replicator.rb`. Implement the `#carrierwave_uploader` method which should return a `CarrierWave::Uploader`, and implement the class method `.model` to return the `CoolWidget` class:
 
   ```ruby
@@ -372,6 +343,7 @@ That's all of the required database changes.
   module Geo
     class CoolWidgetReplicator < Gitlab::Geo::Replicator
       include ::Geo::BlobReplicatorStrategy
+      extend ::Gitlab::Utils::Override
 
       def self.model
         ::CoolWidget
@@ -459,7 +431,7 @@ That's all of the required database changes.
 
   FactoryBot.define do
     factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
-      cool_widget
+      cool_widget # This association should have data, like a file or repository
       state { Geo::CoolWidgetRegistry.state_value(:pending) }
 
       trait :synced do
@@ -508,6 +480,119 @@ That's all of the required database changes.
   end
   ```
 
+- [ ] Add the following to `spec/factories/cool_widgets.rb`:
+
+  ```ruby
+  trait(:verification_succeeded) do
+    with_file
+    verification_checksum { 'abc' }
+    verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
+  end
+
+  trait(:verification_failed) do
+    with_file
+    verification_failure { 'Could not calculate the checksum' }
+    verification_state { CoolWidget.verification_state_value(:verification_failed) }
+  end
+  ```
+
+- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
+
+##### If you added verification state fields to a separate table (option 2 above), then you need to make additional model and factory changes
+
+If you did not add verification state fields to a separate table, `cool_widget_states`, then skip to [Step 2. Implement metrics gathering](#step-2-implement-metrics-gathering).
+
+Otherwise, you can follow [the example of Merge Request Diffs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309).
+
+- [ ] Add a `Geo::CoolWidgetState` model in `ee/app/models/ee/geo/cool_widget_state.rb`:
+
+  ``` ruby
+  module Geo
+    class CoolWidgetState < ApplicationRecord
+      self.primary_key = :cool_widget_id
+
+      belongs_to :cool_widget, inverse_of: :cool_widget_state
+    end
+  end
+  ```
+
+- [ ] Add a `factory` for `cool_widget_state`, in `ee/spec/factories/geo/cool_widget_states.rb`:
+
+  ``` ruby
+  # frozen_string_literal: true
+
+  FactoryBot.define do
+    factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
+      cool_widget
+
+      trait(:checksummed) do
+        verification_checksum { 'abc' }
+      end
+
+      trait(:checksum_failure) do
+        verification_failure { 'Could not calculate the checksum' }
+      end
+    end
+  end
+  ```
+
+- [ ] Add the following lines to the `cool_widget` model to accomplish some important tasks:
+  - Include the `::Gitlab::Geo::VerificationState` concern.
+  - Delegate verification related methods to the `cool_widget_state` model.
+  - Override some scopes to use the `cool_widget_states` table instead of the model table, for verification.
+  - Override some methods to use the `cool_widget_states` table in verification related queries.
+
+  ```ruby
+  class CoolWidget < ApplicationRecord
+    ...
+    include ::Gitlab::Geo::VerificationState
+
+    has_one :cool_widget_state, autosave: true, inverse_of: :cool_widget, class_name: 'Geo::CoolWidgetState'
+
+    delegate :verification_retry_at, :verification_retry_at=,
+             :verified_at, :verified_at=,
+             :verification_checksum, :verification_checksum=,
+             :verification_failure, :verification_failure=,
+             :verification_retry_count, :verification_retry_count=,
+             :verification_state=, :verification_state,
+             :verification_started_at=, :verification_started_at,
+             to: :cool_widget_state
+    ...
+
+    scope :with_verification_state, ->(state) { joins(:cool_widget_state).where(cool_widget_states: { verification_state: verification_state_value(state) }) }
+    scope :checksummed, -> { joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil } ) }
+    scope :not_checksummed, -> { joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil } ) }
+
+    ...
+
+    class_methods do
+      extend ::Gitlab::Utils::Override
+      ...
+      override :verification_state_table_name
+      def verification_state_table_name
+        'cool_widget_states'
+      end
+
+      override :verification_state_model_key
+      def verification_state_model_key
+        'cool_widget_id'
+      end
+
+      override :verification_arel_table
+      def verification_arel_table
+        CoolWidgetState.arel_table
+      end
+    end
+    ...
+
+    def cool_widget_state
+      super || build_cool_widget_state
+    end
+
+    ...
+  end
+  ```
+
 #### Step 2. Implement metrics gathering
 
 Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus` for display in the UI, and sent to Prometheus:
@@ -544,24 +629,6 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
   Geo::CoolWidgetReplicator | :cool_widget | :geo_cool_widget_registry
   ```
 
-- [ ] Add the following to `spec/factories/cool_widgets.rb`:
-
-  ```ruby
-  trait(:verification_succeeded) do
-    with_file
-    verification_checksum { 'abc' }
-    verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-  end
-
-  trait(:verification_failed) do
-    with_file
-    verification_failure { 'Could not calculate the checksum' }
-    verification_state { CoolWidget.verification_state_value(:verification_failed) }
-  end
-  ```
-
-- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
-
 Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
 
 #### Step 3. Implement the GraphQL API
@@ -702,7 +769,10 @@ Individual Cool Widget replication and verification data should now be available
   module Geo
     class CoolWidgetReplicator < Gitlab::Geo::Replicator
       ...
+      # REMOVE THIS LINE IF IT IS NO LONGER NEEDED
+      extend ::Gitlab::Utils::Override
 
+      ...
       # REMOVE THIS METHOD
       def self.replication_enabled_by_default?
         false
diff --git a/.gitlab/issue_templates/Security developer workflow.md b/.gitlab/issue_templates/Security developer workflow.md
index 25825fc8888..99149442509 100644
--- a/.gitlab/issue_templates/Security developer workflow.md	
+++ b/.gitlab/issue_templates/Security developer workflow.md	
@@ -10,10 +10,11 @@ Set the title to: `Description of the original issue`
 
 - [ ] Read the [security process for developers] if you are not familiar with it.
   - Verify if the issue you're working on `gitlab-org/gitlab` is confidential, if it's public fix should be placed on GitLab canonical and no backports are required.
-- [ ] Mark this [issue as linked] to the Security Release Tracking Issue. You can find it on the topic of the `#releases` Slack channel.
+- [ ] **IMPORTANT**: Mark this [issue as linked] to the Security Release Tracking Issue. You can find it on the topic of the `#releases` Slack channel. This issue
+MUST be linked for the release bot to know that the associated merge requests should be merged for this security release.
 - Fill out the [Links section](#links):
   - [ ] Next to **Issue on GitLab**, add a link to the `gitlab-org/gitlab` issue that describes the security vulnerability.
-- [ ] Add one of the `~severity::x` labels to the issue and all associated merge requests. 
+- [ ] Add one of the `~severity::x` labels to the issue and all associated merge requests.
 
 ## Development
 
diff --git a/.gitlab/issue_templates/Snowplow event tracking.md b/.gitlab/issue_templates/Snowplow event tracking.md
index 4a906b61378..ee8755d3292 100644
--- a/.gitlab/issue_templates/Snowplow event tracking.md	
+++ b/.gitlab/issue_templates/Snowplow event tracking.md	
@@ -4,7 +4,7 @@
 * Snowplow is currently not used for self-hosted instances of GitLab - Self-hosted still rely on usage ping for product analytics - Snowplow is used for GitLab SaaS
 * You do not need to create an issue to track generic front-end events, such as All page views, sessions, link clicks, some button clicks, etc.
 * What you should capture are specific events with defined business logic. For example, when a user creates an incident by escalating an existing alert, or when a user creates and pushes up a new Node package to the NPM registry.
-* For more details read https://about.gitlab.com/handbook/business-ops/data-team/programs/data-for-product-managers/
+* For more details read https://about.gitlab.com/handbook/business-technology/data-team/programs/data-for-product-managers/
  -->
 
 <!--
-- 
cgit v1.2.3