Add latest changes from gitlab-org/gitlab@master

5 files changed, 32 insertions, 11 deletions

diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index 047a2064f6f..360ebcc3e52 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -358,6 +358,11 @@ with latest `master`, and then it triggers a regular branch pipeline for
 never be merged back to `master`. Any other Ruby 3 changes should go into
 `master` directly, which should be compatible with Ruby 2.7.
 
+Previously, `ruby3-sync` was using a project token stored in `RUBY3_SYNC_TOKEN`
+(now backed up in `RUBY3_SYNC_TOKEN_NOT_USED`), however due to various
+permissions issues, we ended up using an access token from `gitlab-bot` so now
+`RUBY3_SYNC_TOKEN` is actually an access token from `gitlab-bot`.
+
 ### Long-term plan
 
 We follow the [PostgreSQL versions shipped with Omnibus GitLab](../administration/package_information/postgresql_versions.md):
diff --git a/doc/development/sec/index.md b/doc/development/sec/index.md
index baea583e1ce..294dad4048a 100644
--- a/doc/development/sec/index.md
+++ b/doc/development/sec/index.md
@@ -45,7 +45,7 @@ flowchart LR
 ### Scanning
 
 The scanning part is responsible for finding vulnerabilities in given resources, and exporting results.
-The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/index.md#analyzer), which can be found in our [Analyzers sub-group](https://gitlab.com/gitlab-org/security-products/analyzers).
+The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/index.md#analyzer), which can be found in our [Analyzers subgroup](https://gitlab.com/gitlab-org/security-products/analyzers).
 The Analyzers are wrappers around security tools called [Scanners](../../user/application_security/terminology/index.md#scanner), developed internally or externally, to integrate them into GitLab.
 The Analyzers are mainly written in Go.
 
diff --git a/doc/development/testing_guide/end_to_end/beginners_guide.md b/doc/development/testing_guide/end_to_end/beginners_guide.md
index bceb0d12fde..b81379d89b2 100644
--- a/doc/development/testing_guide/end_to_end/beginners_guide.md
+++ b/doc/development/testing_guide/end_to_end/beginners_guide.md
@@ -120,6 +120,22 @@ module QA
 end
 ```
 
+### The `product_group` metadata
+
+Assign `product_group` metadata and specify what product group this test belongs to. In this case, `authentication_and_authorization`.
+
+```ruby
+# frozen_string_literal: true
+
+module QA
+  RSpec.describe 'Manage' do
+    describe 'Login', product_group: :authentication_and_authorization do
+
+    end
+  end
+end
+```
+
 ### The `it` blocks (examples)
 
 Every test suite contains at least one `it` block (example). A good way to start
@@ -128,7 +144,7 @@ writing end-to-end tests is to write test case descriptions as `it` blocks:
 ```ruby
 module QA
   RSpec.describe 'Manage' do
-    describe 'Login' do
+    describe 'Login', product_group: :authentication_and_authorization do
       it 'can login' do
 
       end
@@ -152,7 +168,7 @@ Begin by logging in.
 
 module QA
   RSpec.describe 'Manage' do
-    describe 'Login' do
+    describe 'Login', product_group: :authentication_and_authorization do
       it 'can login' do
         Flow::Login.sign_in
 
@@ -175,7 +191,7 @@ should answer the question "What do we test?"
 
 module QA
   RSpec.describe 'Manage' do
-    describe 'Login' do
+    describe 'Login', product_group: :authentication_and_authorization do
       it 'can login' do
         Flow::Login.sign_in
 
@@ -222,7 +238,7 @@ a call to `sign_in`.
 
 module QA
   RSpec.describe 'Manage' do
-    describe 'Login' do
+    describe 'Login', product_group: :authentication_and_authorization do
       before do
         Flow::Login.sign_in
       end
@@ -251,7 +267,7 @@ ensuring we now sign in at the beginning of each test.
 ## Test setup using resources and page objects
 
 Next, let's test something other than Login. Let's test Issues, which are owned by the Plan
-stage, so [create a file](#identify-the-devops-stage) in
+stage and the Project Management Group, so [create a file](#identify-the-devops-stage) in
 `qa/specs/features/browser_ui/3_create/issues` called `issues_spec.rb`.
 
 ```ruby
@@ -259,7 +275,7 @@ stage, so [create a file](#identify-the-devops-stage) in
 
 module QA
   RSpec.describe 'Plan' do
-    describe 'Issues' do
+    describe 'Issues', product_group: :project_management do
       let(:issue) do
         Resource::Issue.fabricate_via_api! do |issue|
           issue.title = 'My issue'
diff --git a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md
index 3391c80aca0..0b7e1bd46da 100644
--- a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md
+++ b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md
@@ -43,7 +43,7 @@ Benefits of the aggregated VSA backend:
 - Simpler database queries (fewer JOINs).
 - Faster aggregations, only a single table is accessed.
 - Possibility to introduce further aggregations for improving the first page load time.
-- Better performance for large groups (with many sub-groups, projects, issues and, merge requests).
+- Better performance for large groups (with many subgroups, projects, issues and, merge requests).
 - Ready for database decomposition. The VSA related database tables could live in a separate
 database with a minimal development effort.
 - Ready for keyset pagination which can be useful for exporting the data.
@@ -165,7 +165,7 @@ Creation time always happens first, so this stage always reports negative durati
 
 The data collection scans and processes all issues and merge requests records in the group
 hierarchy, starting from the top-level group. This means that if a group only has one value stream
-in a sub-group, we nevertheless collect data of all issues and merge requests in the hierarchy of
+in a subgroup, we nevertheless collect data of all issues and merge requests in the hierarchy of
 this group. This aims to simplify the data collection mechanism. Moreover, data research shows
 that most group hierarchies have their stages configured on the top level.
 
diff --git a/doc/development/work_items.md b/doc/development/work_items.md
index 5f0ef88f200..eabad175bf7 100644
--- a/doc/development/work_items.md
+++ b/doc/development/work_items.md
@@ -88,8 +88,8 @@ so that in future we can allow users to define custom WITs, we will move the
 to `work_item_types` will involve creating the set of WITs for all root-level groups.
 
 NOTE:
-At first, defining a WIT will only be possible at the root-level group, which would then be inherited by sub-groups.
-We will investigate the possibility of defining new WITs at sub-group levels at a later iteration.
+At first, defining a WIT will only be possible at the root-level group, which would then be inherited by subgroups.
+We will investigate the possibility of defining new WITs at subgroup levels at a later iteration.
 
 ### Introducing work_item_types table