Automatic merge of gitlab-org/gitlab master

.gitlab/issue_templates/Audit Event Proposal.md

@@ -9,5 +9,5 @@
 <!-- Describe the audit event you are proposing should be added, including any details of what should be captured, how, and why. -->
 
 /label ~"Category:Audit Events"
-/label ~"feature"
+/label ~"type::feature"
 /label ~"group::compliance"

.gitlab/issue_templates/Bug.md

@@ -2,10 +2,10 @@
 Please read this!
 
 Before opening a new issue, make sure to search for keywords in the issues
-filtered by the "regression" or "bug" label:
+filtered by the "regression" or "type::bug" label:
 
 - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
-- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
+- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug
 
 and verify the issue you're about to submit isn't a duplicate.
 --->
@@ -82,4 +82,4 @@ will also determine whether the bug is fixed in a more recent version. -->
 
 <!-- If you can, link to the line of code that might be responsible for the problem. -->
 
-/label ~bug
+/label ~"type::bug"

.gitlab/issue_templates/Experiment Successful Cleanup.md

@@ -17,4 +17,4 @@ The changes need to become an official part of the product.
 - [ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
 - [ ] Ensure the corresponding [Experiment Tracking](https://gitlab.com/groups/gitlab-org/-/boards/1352542?label_name[]=devops%3A%3Agrowth&label_name[]=growth%20experiment&label_name[]=experiment%20tracking) issue is updated
 
-/label ~"feature" ~"feature::maintenance" ~"workflow::scheduling" ~"growth experiment" ~"feature flag"  
+/label ~"type::maintenance" ~"workflow::scheduling" ~"growth experiment" ~"feature flag"

.gitlab/issue_templates/Feature Proposal - basic.md

@@ -7,4 +7,4 @@
 <!-- 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 ~feature::addition ~"group::" ~"section::" ~"Category:" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"
+/label ~"type::feature" ~feature::addition ~"group::" ~"section::" ~"Category:" ~"GitLab Core"/~"GitLab Premium"/~"GitLab Ultimate"

.gitlab/issue_templates/Feature Proposal - lean.md

@@ -14,7 +14,7 @@
 
 
 
-/label ~"feature" ~"group::" ~"section::"  ~"Category::" ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
+/label ~"type::feature" ~"group::" ~"section::"  ~"Category::" ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
 
 
 <!--- Use the following resources to find the appropriate labels:

.gitlab/issue_templates/Feature proposal - detailed.md

@@ -112,6 +112,4 @@ Use the following resources to find the appropriate labels:
 -->
 /label ~devops:: ~group: ~Category:
 /label  ~"GitLab Free"/~"GitLab Premium"/~"GitLab Ultimate"
-/label ~feature
-/label ~documentation
-/label ~direction
+/label ~"type::feature" ~documentation ~direction

.gitlab/issue_templates/InfraDev.md

@@ -53,4 +53,4 @@ See also:
 -->
 
 /label ~"infradev"
-/label ~"bug"
+/label ~"type::bug"

.gitlab/issue_templates/Refactoring.md

@@ -41,9 +41,9 @@ please list them here.
 <!--
 Please select the appropriate label from the following:
     ~"feature::addition"
-    ~"feature::maintenance"
+    ~"type::maintenance"
     ~"tooling::pipelines"
     ~"tooling::workflow"
 -->
 
-/label ~"feature::maintenance"
+/label ~"type::maintenance"

.gitlab/issue_templates/Technical Evaluation.md

@@ -29,5 +29,5 @@
 
 ### Team
 
-- [ ] Add ~"workflow::planning breakdown" ~feature and the corresponding `~devops::<stage>` and `~group::<group>` labels.
+- [ ] Add ~"workflow::planning breakdown" ~"type::feature" and the corresponding `~devops::<stage>` and `~group::<group>` labels.
 - [ ] Ping the PM and EM.

.gitlab/merge_request_templates/Documentation.md

@@ -20,10 +20,10 @@
 
 If you are only adding documentation, do not add any of the following labels:
 
-- `~"feature"`
+- `~"type::feature"`
 - `~"frontend"`
 - `~"backend"`
-- `~"bug"`
+- `~"type::bug"`
 - `~"database"`
 
 These labels cause the MR to be added to code verification QA issues.

.gitlab/merge_request_templates/New End To End Test.md

@@ -24,5 +24,5 @@ Please link to the respective test case in the testcases project
 
 /label ~"Quality:test-gap" ~"Quality:EE test gaps"
 
-<!-- Select the appropriate feature label, ~"feature::addition" for tests added for new features, ~"feature::maintenance" for tests added for existing features -->
-/label ~"feature::addition" ~"feature::maintenance" 
+<!-- Select the appropriate feature label, ~"feature::addition" for tests added for new features, ~"type::maintenance" for tests added for existing features -->
+/label ~"feature::addition" ~"type::maintenance"

.gitlab/merge_request_templates/Pipeline Configuration.md

@@ -35,4 +35,4 @@ This will help keep track of expected cost increases to the [GitLab project aver
 
 - [ ] Consider communicating these changes to the broader team following the [communication guideline for pipeline changes](https://about.gitlab.com/handbook/engineering/quality/engineering-productivity/#pipeline-changes)
 
-/label ~tooling ~"tooling::pipelines" ~"Engineering Productivity"
+/label ~"type::tooling" ~"tooling::pipelines" ~"Engineering Productivity"

.gitlab/merge_request_templates/Quarantine End to End Test.md

@@ -30,7 +30,7 @@ the noise (due to constantly failing tests, flaky tests, and so on) so that new
 - [ ] To ensure a faster turnaround, ask in the `#quality` Slack channel for someone to review and merge the merge request, rather than assigning it directly.
 
 <!-- Base labels. -->
-/label ~"Quality" ~"QA" ~"feature" ~"feature::maintenance"
+/label ~"Quality" ~"QA" ~"type::maintenance"
 
 <!--
 Choose the stage that appears in the test path, e.g. ~"devops::create" for

danger/metadata/Dangerfile

@@ -4,24 +4,21 @@
 
 DEFAULT_BRANCH = 'master'
 
-THROUGHPUT_LABELS = [
-  'Community contribution',
-  'security',
-  'bug',
-  'feature',
+TYPE_LABELS = [
+  'type::feature',
   'feature::addition',
-  'feature::maintenance',
-  'tooling',
+  'type::maintenance',
+  'type::tooling',
   'tooling::pipelines',
   'tooling::workflow',
-  'documentation'
+  'type::bug'
 ].freeze
 
 if gitlab.mr_body.size < 5
   fail "Please provide a proper merge request description."
 end
 
-if (THROUGHPUT_LABELS & gitlab.mr_labels).empty?
+if (TYPE_LABELS & gitlab.mr_labels).empty?
   warn 'Please add a [merge request type](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) to this merge request.'
 end
 

danger/specialization_labels/Dangerfile

@@ -8,7 +8,7 @@ SPECIALIZATIONS = {
   frontend: 'frontend',
   docs: 'documentation',
   qa: 'QA',
-  tooling: 'tooling',
+  tooling: 'type::tooling',
   ci_template: 'ci::templates',
   feature_flag: 'feature flag'
 }.freeze

danger/specs/Dangerfile

 # frozen_string_literal: true
 
 NO_SPECS_LABELS = [
-  'tooling',
+  'type::tooling',
   'tooling::pipelines',
   'tooling::workflow',
   'documentation',

doc/architecture/blueprints/feature_flags_development/index.md

@@ -29,7 +29,7 @@ The extensive usage of feature flags poses a few challenges
   We sometimes forget how our feature flags are configured or why we haven't
   yet removed the feature flag.
 - The usage of feature flags can also be confusing to people outside of
-  development that might not fully understand dependence of ~feature or ~bug
+  development that might not fully understand dependence of ~"type::feature" or ~"type::bug"
   fix on feature flag and how this feature flag is configured. Or if the feature
   should be announced as part of release post.
 - Maintaining feature flags poses additional challenge of having to manage

doc/development/contributing/issue_workflow.md

@@ -45,7 +45,7 @@ scheduling into milestones. Labeling is a task for everyone. (For some projects,
 
 Most issues will have labels for at least one of the following:
 
-- Type. For example: `~feature`, `~bug`, `~tooling`, or `~documentation`.
+- Type. For example: `~"type::feature"`, `~"type::bug"`, or `~"type::tooling"`.
 - Stage. For example: `~"devops::plan"` or `~"devops::create"`.
 - Group. For example: `~"group::source code"`, `~"group::knowledge"`, or `~"group::editor"`.
 - Category. For example: `~"Category:Code Analytics"`, `~"Category:DevOps Reports"`, or `~"Category:Templates"`.
@@ -70,12 +70,12 @@ issue should have one and only one.
 
 The current type labels are:
 
-- `~feature`
+- `~"type::feature"`
   - `~"feature::addition"`
   - `~"feature::enhancement"`
-  - `~"feature::maintenance"`
-- `~bug`
-- `~tooling`
+- `~"type::maintenance"`
+- `~"type::bug"`
+- `~"type::tooling"`
   - `~"tooling::pipelines"`
   - `~"tooling::workflow"`
 - `~"support request"`
@@ -342,11 +342,11 @@ To create a feature proposal, open an issue on the
 [issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
 
 In order to help track the feature proposals, we have created a
-[`feature`](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=feature) label.
+[`~"type::feature"`](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name=type::feature) label.
 For the time being, users that are not members of the project cannot add labels.
 You can instead ask one of the [core team](https://about.gitlab.com/community/core-team/)
-members to add the label `~feature` to the issue or add the following
-code snippet right after your description in a new line: `~feature`.
+members to add the label `~"type::feature"` to the issue or add the following
+code snippet right after your description in a new line: `~"type::feature"`.
 
 Please keep feature proposals as small and simple as possible, complex ones
 might be edited to make them small and simple.

doc/development/documentation/workflow.md

@@ -39,7 +39,7 @@ The following are also added by members of the Technical Writing team:
 - The `~Technical Writing` [team label](../contributing/issue_workflow.md#team-labels).
 
 Documentation changes that are not associated with the release of a new or updated feature
-do not take the `~feature` label, but still need the `~documentation` label.
+do not take the `~"type::feature"` label, but still need the `~documentation` label.
 
 They may include:
 

doc/development/testing_guide/review_apps.md

@@ -180,7 +180,7 @@ subgraph "CNG-mirror pipeline"
 **Additional notes:**
 
 - If the `review-deploy` job keeps failing (and a manual retry didn't help),
-  please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~bug`
+  please post a message in the `#g_qe_engineering_productivity` channel and/or create a `~"Engineering Productivity"` `~"ep::review apps"` `~"type::bug"`
   issue with a link to your merge request. Note that the deployment failure can
   reveal an actual problem introduced in your merge request (i.e. this isn't
   necessarily a transient failure)!
@@ -189,7 +189,7 @@ subgraph "CNG-mirror pipeline"
   your merge request. You can also download the artifacts to see screenshots of
   the page at the time the failures occurred. If you don't find the cause of the
   failure or if it seems unrelated to your change, please post a message in the
-  `#quality` channel and/or create a ~Quality ~bug issue with a link to your
+  `#quality` channel and/or create a ~Quality ~"type::bug" issue with a link to your
   merge request.
 - The manual `review-stop` can be used to
   stop a Review App manually, and is also started by GitLab once a merge

spec/tooling/danger/changelog_spec.rb

@@ -228,7 +228,7 @@ RSpec.describe Tooling::Danger::Changelog do
       end
 
       context 'with changelog label' do
-        let(:mr_labels) { ['feature'] }
+        let(:mr_labels) { ['type::feature'] }
 
         it 'is truthy' do
           is_expected.to be_truthy
@@ -236,7 +236,7 @@ RSpec.describe Tooling::Danger::Changelog do
       end
 
       context 'with no changelog label' do
-        let(:mr_labels) { ['tooling'] }
+        let(:mr_labels) { ['type::tooling'] }
 
         it 'is truthy' do
           is_expected.to be_falsey

tooling/danger/changelog.rb

@@ -6,7 +6,7 @@ module Tooling
   module Danger
     module Changelog
       NO_CHANGELOG_LABELS = [
-        'tooling',
+        'type::tooling',
         'tooling::pipelines',
         'tooling::workflow',
         'ci-build',