Add latest changes from gitlab-org/gitlab@15-3-stable-eev15.3.0-rc42

9 files changed, 108 insertions, 110 deletions

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 e1c5928b950..7ef5287aba8 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
@@ -392,7 +392,7 @@ That's all of the required database changes.
   ```
 
 - [ ] Update `REGISTRY_CLASSES` in `ee/app/workers/geo/secondary/registry_consistency_worker.rb`.
-- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/services/geo/registry_consistency_service_spec.rb`.
+- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/support/helpers/ee/geo_helpers.rb`.
 - [ ] Update `it 'creates missing registries for each registry class'` in `ee/spec/workers/geo/secondary/registry_consistency_worker_spec.rb`.
 - [ ] Add `cool_widget_registry` to `ActiveSupport::Inflector.inflections` in `config/initializers_before_autoloader/000_inflections.rb`.
 - [ ] Create `ee/spec/factories/geo/cool_widget_registry.rb`:
@@ -539,11 +539,6 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
   - `geo_cool_widgets_verification_total`
   - `geo_cool_widgets_verified`
   - `geo_cool_widgets_verification_failed`
-- [ ] Add the following to the parameterized table in the `context 'Replicator stats' do` block in `ee/spec/models/geo_node_status_spec.rb`:
-
-  ```ruby
-  Geo::CoolWidgetReplicator | :cool_widget | :geo_cool_widget_registry
-  ```
 
 Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
 
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 9158885262d..17a4dd4bc3e 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -358,7 +358,7 @@ That's all of the required database changes.
   ```
 
 - [ ] Update `REGISTRY_CLASSES` in `ee/app/workers/geo/secondary/registry_consistency_worker.rb`.
-- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/services/geo/registry_consistency_service_spec.rb`.
+- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/support/helpers/ee/geo_helpers.rb`.
 - [ ] Update `it 'creates missing registries for each registry class'` in `ee/spec/workers/geo/secondary/registry_consistency_worker_spec.rb`.
 - [ ] Add `cool_widget_registry` to `ActiveSupport::Inflector.inflections` in `config/initializers_before_autoloader/000_inflections.rb`.
 - [ ] Create `ee/spec/factories/geo/cool_widget_registry.rb`:
@@ -503,11 +503,6 @@ Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus`
   - `geo_cool_widgets_verification_total`
   - `geo_cool_widgets_verified`
   - `geo_cool_widgets_verification_failed`
-- [ ] Add the following to the parameterized table in the `context 'Replicator stats' do` block in `ee/spec/models/geo_node_status_spec.rb`:
-
-  ```ruby
-  Geo::CoolWidgetReplicator | :cool_widget | :geo_cool_widget_registry
-  ```
 
 Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Nodes` view, and Prometheus.
 
diff --git a/.gitlab/issue_templates/Implementation.md b/.gitlab/issue_templates/Implementation.md
index f57bfae4da3..e09f807d3d9 100644
--- a/.gitlab/issue_templates/Implementation.md
+++ b/.gitlab/issue_templates/Implementation.md
@@ -37,13 +37,20 @@ Add details for required items and delete others.
 
 ## Implementation plan
 <!--
-Steps and the parts of the code that will need to get updated. The plan can also
-call-out responsibilities for other team members or teams.
+Steps and the parts of the code that will need to get updated.
+The plan can also call-out responsibilities for other team members or teams and
+can be split into smaller MRs to simplify the code review process.
 
 e.g.:
 
+- MR 1: Part 1
+- [ ] ~frontend Step 1
+- [ ] ~frontend Step 2
+- MR 2: Part 2
+- [ ] ~backend Step 1
+- [ ] ~backend Step 2
+- MR 3: Part 3
 - [ ] ~frontend Step 1
-  - [ ] `@person` Step 1a
 - [ ] ~frontend Step 2
 
 -->
diff --git a/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md b/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md
index e9e510da11e..3939fca44f1 100644
--- a/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md
+++ b/.gitlab/issue_templates/Navigation - Left Sidebar Proposals.md
@@ -6,7 +6,7 @@
 
 ### Checklist
 
-- [ ] If your proposal includes changes to the top-level menu items within the left sidebar, engage the [Foundations Product Design Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI will work with UX partners in product design, research, and technical writing, as applicable.
+- [ ] If your proposal includes changes to the menu items within the left sidebar, engage the [Foundations Product Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI will work with UX partners in product design, research, and technical writing, as applicable.
 - [ ] Follow the [product development workflow](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is strongly encouraged.
 - [ ] Engage the [Foundations](https://about.gitlab.com/handbook/product/categories/#foundations-group) team to ensure your proposal is in alignment with holistic changes happening to the left side bar.
 - [ ] Consider whether you need to communicate the change somehow, or if you will have an interim period in the UI where your nav item will live in more than one place.
diff --git a/.gitlab/issue_templates/OSS_Partner.md b/.gitlab/issue_templates/OSS_Partner.md
deleted file mode 100644
index d9c05026e7c..00000000000
--- a/.gitlab/issue_templates/OSS_Partner.md
+++ /dev/null
@@ -1,68 +0,0 @@
-<!-- Please title your issue with the following format: "Project Name | Issue Tracker". -->
-
-## Background
-
-<!-- 
-Please add information here about why your project is considering a migration to GitLab, or why it decided to do so. Include any initial announcements that have been / were made about the decision or status.
--->
-
-### Goals
-
-<!-- What are some of the goals of your migration to GitLab? Delete this section if you don't want to enumerate goals. -->
-
-## Quick Facts
-
-<!-- Please complete as many items in this list as possible. If you're not sure yet, add "TBD" (To be Decided) or "Unknown" -->
-
- * **Timeline.** - 
- * **Product.** - SaaS-Ultimate/Self-Managed-Ultimate or Community Edition
- * **Project's License.** What kind of OSI-approved license does your project use? 
-
-## Current Tooling and Replacements
-
-<!-- 
-Please fill in the table to give an overview of your current tooling. Here's a description of what to include in each column:  
-
-- Tool: which tool or platform you are currently using
-- Feature: which particular feature you are using in that tool or platform
-- GitLab feature: equivalent GitLab feature (the GitLab team can help fill this in, as well as the info in the next column)
-- GitLab edition: in which GitLab edition (CE or EE) is this feature available? 
-
-Here's an example of a replacements overview from one of the projects which migrated to GitLab:  https://gitlab.com/gitlab-org/gitlab/-/issues/25657#gitlab-replacements
-
-Consider deleting the table below if you are unable to expand upon your current tooling.
-
--->
-
-| Tool | Feature | GitLab feature | GitLab edition |
-| --- | --- | --- | --- |
-|  |  |  |  |
-
-## Collaborators
-
-<!-- Please add names of collaborators in the format: Name, Title, Role (what will you be helping to do, or how should you be involved), GitLab username -->
-
-## Related Issues
-
-<!-- Add any related issues that are important for your project by adding the title of the issue and a link to it (preferably as an embedded link). You will probably keep editing this section as the migration progresses, so don't worry if it's mostly blank for now. 
-
-Here is an example of what this list might look like once populated: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55039#outstanding-issues
--->
-
-### Blockers
- * [ ] ADD_LINK_TO_ISSUE_HERE
-
-### Urgent
- * [ ] 
-
-### Important but not urgent
- * [ ] 
-
-### Nice to have
- * [ ] 
-
- 
-------
-
-/label ~"Open Source Partners"
-/cc @nuritzi @greg
diff --git a/.gitlab/issue_templates/Performance Indicator Metric.md b/.gitlab/issue_templates/Performance Indicator Metric.md
deleted file mode 100644
index 8019be8cad5..00000000000
--- a/.gitlab/issue_templates/Performance Indicator Metric.md
+++ /dev/null
@@ -1,23 +0,0 @@
-<!--
-Performance Indicator Metric issues are used for adding, updating, or removing performance indicator type in Service Ping metrics.
-
-Please title your issue with the following format: "{action}(Add|Update|Remove) Metric name as performance indicator"
-
-Example of title: "Add some_feature_views as gmau"
-
--->
-
-## Summary
-
-<!--
-Summary of the changes
--->
-
-## Tasks
-
-- [ ] [Link to metric definition]()
-- [ ] Create issue in GitLab Data Team project using [Product Performance Indicator template](https://gitlab.com/gitlab-data/analytics/-/issues/new?issuable_template=Product%20Performance%20Indicator%20Template)
-
-See [Product Intelligence Guide](https://docs.gitlab.com/ee/development/service_ping/performance_indicator_metrics.html) for details
-
-/label ~"product intelligence" ~"Data Warehouse::Impact Check"
diff --git a/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
index 4544e675256..523a50dfdf8 100644
--- a/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
+++ b/.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md
@@ -12,6 +12,21 @@
 
 ## Proposal
 
+## Additional details
+<!--
+_NOTE: If the issue has addressed all of these questions, this separate section can be removed._
+-->
+
+Some relevant technical details, if applicable, such as:
+
+- Does this need a ~"feature flag"?
+- Is there an example response showing the data structure that should be returned (new endpoints only)?
+- What permissions should be used?
+- Is this EE or CE?
+    - [ ] EE
+    - [ ] CE
+- Additional comments:
+
 ## Implementation Table
 
 <!--
diff --git a/.gitlab/issue_templates/Service Ping reporting and monitoring.md b/.gitlab/issue_templates/Service Ping reporting and monitoring.md
index 1c0d221318b..9a30f71e42b 100644
--- a/.gitlab/issue_templates/Service Ping reporting and monitoring.md
+++ b/.gitlab/issue_templates/Service Ping reporting and monitoring.md
@@ -1,6 +1,6 @@
-<!-- This issue template is used by https://about.gitlab.com/handbook/engineering/development/growth/product-intelligence/ for tracking effort around Service Ping reporting for GitLab.com -->
+<!-- This issue template is used by https://about.gitlab.com/handbook/engineering/development/analytics-section/product-intelligence/ for tracking effort around Service Ping reporting for GitLab.com -->
 
-The [Product Intelligence group](https://about.gitlab.com/handbook/engineering/development/growth/product-intelligence/) runs manual reporting of ServicePing for GitLab.com on a weekly basis. This issue captures:
+The [Product Intelligence group](https://about.gitlab.com/handbook/engineering/development/analytics/product-intelligence/) runs manual reporting of ServicePing for GitLab.com on a weekly basis. This issue:
 
 - Captures the work required to complete the reporting process,.
 - Captures the follow-up tasks that are focused on metrics performance verification.
@@ -123,7 +123,7 @@ If you get mentioned, check the failing metric and open an optimization issue.
 <!-- Do not edit below this line -->
 
 /confidential
-/label ~"group::product intelligence" ~"devops::growth" ~backend ~"section::growth" ~"Category:Service Ping"
+/label ~"group::product intelligence" ~"devops::analytics" ~backend ~"section::analytics" ~"Category:Service Ping"
 /epic https://gitlab.com/groups/gitlab-org/-/epics/6000
 /weight 5
 /title Monitor and Generate GitLab.com Service Ping
diff --git a/.gitlab/issue_templates/UX Theme.md b/.gitlab/issue_templates/UX Theme.md
new file mode 100644
index 00000000000..043cb705352
--- /dev/null
+++ b/.gitlab/issue_templates/UX Theme.md
@@ -0,0 +1,77 @@
+<!-- A majority of the work designers do will be on themes in the (Now) Next 1-3 milestone column. These themes are comprised of high-confidence outcomes and validated needs. The UX theme issue is where collaboration should occur, including plans and discussion on subthemes, research, and design feedback. Related issues for design exploration and solution validation should stem from the theme issue. 
+
+One of the advantages of working with UX themes is that it allows us to think and design holistically by designing the theme as a whole as opposed to a single issue at a time trying to piece them together as you go. For more details please refer to this section of the handbook when creating UX Themes: https://about.gitlab.com/handbook/engineering/ux/product-design/ux-roadmaps/#theme-structure -->
+
+### UX Theme 
+<!-- A theme is written as a statement that combines the beneficiary, their need, and the expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the theme so that anyone can understand it at a glance. (For instance; Reduce the effort for security teams to identify and escalate business-critical risks) 
+
+!!Note: The theme statement is the defacto title that will be used to reference the theme and serve as the theme issue title.!!
+-->
+
+----
+
+### Problem to solve
+<!-- In a brief statement, summerize the problem we are intending to address with this theme. For instance, users are unable to complete [task], or, users struggle with the amount of steps required to complete [task] -->
+
+
+### Beneficiary 
+<!-- Who is the recipient(s) of the value this theme provides; a customer, end-user, or buyer. Who benefits from this theme being executed? This can be a role, a team, or a persona. For instance: "Development teams, [or] Developers, [or], Sasha the Software Engineer". --> 
+
+- **[Direct beneficiary]**
+
+#### Need & Primary JTBD
+<!-- What is the JTBD and what are the needs related to the beneficiary and theme? 
+- JTBD = The JTBD statement, for instance, (When I am triaging vulns, I want to address business-critical risks, So I can ensure there is no unattended risk in my orgs assets.) 
+- Need = Abstracted from the JTBD, for instance, (Identify and escalate business-critical risks detected in my orgs assets.)
+--> 
+
+- **JTBD:** 
+- **Need:**   
+
+#### Expected outcome
+<!-- What will the user be able to achieve when this theme is executed? For instance, (Users will be able to effectively triage vulnerabilities at scale across all their orgs assets.) -->
+
+
+#### Business objective
+<!-- What business objective will result from delivering this theme? This answers why we are working on this theme from a business perspective. Examples of objectives are but are not limited to: Sales rate / conversion rate, Success rate / completion rate, Traffic / visitor count, Engagement, or other business-oriented goals. --> 
+
+
+#### Confidence
+<!-- How well do we understand the user's problem and their need? Refer to https://about.gitlab.com/handbook/engineering/ux/product-design/ux-roadmaps/#confidence to assess confidence -->
+
+
+| Confidence | Research | 
+| --- | --- | 
+| [High/Medium/Low] | [research/insight issue](Link) |
+
+
+### Subthemes & Requirements
+<!-- Subthemes are more granular validated needs, goals, and additional details that the theme encompasses. These are typically reserved for themes in the next (1-3 milestones) column. Subthemes may also consist of existing feature or design issues that exist in GitLab and directly relate to the theme. Subthemes answer “how” we are going to solve the user need while the theme itself answers “what” the need is and “who” will be benefiting from the solution.
+
+Note: This is not a backlog. If the subthemes can not be delivered in the theme timeframe then the theme is too big and needs to be broken down into multiple themes. -->
+
+#### Feature/solution subthemes
+<!-- Use this table to track feature issues related to this theme (if applicable). Not all themes require subthemes as subthemes are typically discovered while working on the theme itself. Think of subthemes as if they were the result of design breaking down the issue into discrete work items. 
+
+Note: if feature issues already exist then you can add them to this table. Keep in mind that subthemes require validation if they are assumptive 
+
+Refer to https://about.gitlab.com/handbook/engineering/ux/product-designer/#ux-issue-weights for calculating UX weights.
+--> 
+
+| Issue | UX Weight |  
+| ---------- | --------- | 
+| [Issue](link) | `0 - 10` | 
+| [Issue](link) | `0 - 10` | 
+| [Issue](link) | `0 - 10` | 
+
+#### Research subthemes
+<!-- Use this table to track UX research related to this theme. This may include, problem validation and/or solution validation activities. 
+--> 
+
+| Issue | Research type | Research status |
+| ---------- | --------- | --------- |   
+| [Issue]()  | <!--Solution validation, Problem validation, etc., --> |  <!-- Planned, In Progress, Complete, etc.,-->  |  
+| [Issue]()  | <!--Solution validation, Problem validation, etc., --> |  <!-- Planned, In Progress, Complete, etc.,-->  |
+
+
+/label ~"UX"  ~"UX Theme"