Automatic merge of gitlab-org/gitlab master

app/graphql/types/namespace/shared_runners_setting_enum.rb

+# frozen_string_literal: true
+
+module Types
+  class Namespace::SharedRunnersSettingEnum < BaseEnum
+    graphql_name 'SharedRunnersSetting'
+
+    ::Namespace::SHARED_RUNNERS_SETTINGS.each do |type|
+      value type.upcase,
+            description: "Sharing of runners is #{type.tr('_', ' ')}.",
+            value: type
+    end
+  end
+end

app/graphql/types/namespace_type.rb

@@ -42,6 +42,11 @@ module Types
           null: true,
           description: 'The package settings for the namespace.'
 
+    field :shared_runners_setting,
+          Types::Namespace::SharedRunnersSettingEnum,
+          null: true,
+          description: "Shared runners availability for the namespace and its descendants."
+
     def root_storage_statistics
       Gitlab::Graphql::Loaders::BatchRootStorageStatisticsLoader.new(object.id).find
     end

config/metrics/objects_schemas/projects_with_enabled_alert_integrations_histogram.json

 {
   "type": "object",
-  "description": "Histogram (buckets 1 to 100) of projects with at least 1 enabled integration"
+  "description": "Histogram (buckets 1 to 100) of projects with at least 1 enabled integration",
   "propertyNames": {
     "pattern": "^[1-9][0-9]?0?$"
   }

config/metrics/objects_schemas/topology_schema.json

 {
   "type": "object",
-  "required": ["duration", "failures"],
+  "required": ["duration_s", "failures"],
   "properties": {
-    "duration": { "type": "number", "description": "The time it took to collect topology data" },
+    "duration_s": { "type": "number", "description": "The time it took to collect topology data" },
     "failures": { "type": "array", "description": "The information about failed queries" },
     "application_requests_per_hour": { "type": "number", "description": "The number of requests to the web application per hour" },
     "nodes": {

doc/.vale/gitlab/Wordy.yml

+---
+# Suggestion: gitlab.Wordy
+#
+# Suggests shorter versions of wordy phrases.
+#
+# For a list of all options, see https://docs.errata.ai/vale/styles
+extends: substitution
+message: 'Be concise: "%s" is less wordy than "%s".'
+link: https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html
+level: suggestion
+ignorecase: true
+swap:
+  in order to: to

doc/administration/feature_flags.md

@@ -31,16 +31,27 @@ These features can be enabled and disabled to allow or disallow users to use
 them. It can be done by GitLab administrators with access to GitLab Rails
 console.
 
+When you disable a feature flag, the feature is hidden from users and all of the functionality is turned off.
+For example, data is not recorded and services do not run.
+
 If you used a certain feature and identified a bug, a misbehavior, or an
 error, it's very important that you [**provide feedback**](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue[title]=Docs%20-%20feature%20flag%20feedback%3A%20Feature%20Name&issue[description]=Describe%20the%20problem%20you%27ve%20encountered.%0A%0A%3C!--%20Don%27t%20edit%20below%20this%20line%20--%3E%0A%0A%2Flabel%20~%22docs%5C-comments%22%20) to GitLab as soon
 as possible so we can improve or fix it while behind a flag. When you upgrade
 GitLab to an earlier version, the feature flag status may change.
 
-WARNING:
-Features deployed behind feature flags may not be ready for
-production use. However, disabling features behind flags that were deployed
-enabled by default may also present a risk. If they're enabled, we recommend
-you leave them as-is.
+## Risks when enabling features still in development
+
+Features that are disabled by default may change or be removed without notice in a future version of GitLab.
+
+Data corruption, stability degradation, or performance degradation might occur if
+you enable a feature that's disabled by default. Problems caused by using a default
+disabled feature aren't covered by GitLab support, unless you were directed by GitLab
+to enable the feature.
+
+## Risks when disabling released features
+
+In most cases, the feature flag code is removed in a future version of GitLab.
+If and when that occurs, from that point onward you can't keep the feature in a disabled state.
 
 ## How to enable and disable features behind flags
 

doc/administration/instance_limits.md

@@ -491,7 +491,7 @@ A runner's registration fails if it exceeds the limit for the scope determined b
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-job-log-limits). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 The job log file size limit is 100 megabytes by default. Any job that exceeds this value is dropped.

doc/api/graphql/custom_emoji.md

@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-custom-emoji-api). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 To use custom emoji in comments and descriptions, you can add them to a group using the GraphQL API.

doc/api/graphql/reference/index.md

@@ -9434,6 +9434,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="grouprequiretwofactorauthentication"></a>`requireTwoFactorAuthentication` | [`Boolean`](#boolean) | Indicates if all users in this group are required to set up two-factor authentication. |
 | <a id="grouprootstoragestatistics"></a>`rootStorageStatistics` | [`RootStorageStatistics`](#rootstoragestatistics) | Aggregated storage statistics of the namespace. Only available for root namespaces. |
 | <a id="groupsharewithgrouplock"></a>`shareWithGroupLock` | [`Boolean`](#boolean) | Indicates if sharing a project with another group within this group is prevented. |
+| <a id="groupsharedrunnerssetting"></a>`sharedRunnersSetting` | [`SharedRunnersSetting`](#sharedrunnerssetting) | Shared runners availability for the namespace and its descendants. |
 | <a id="groupstats"></a>`stats` | [`GroupStats`](#groupstats) | Group statistics. |
 | <a id="groupstoragesizelimit"></a>`storageSizeLimit` | [`Float`](#float) | Total storage limit of the root namespace in bytes. |
 | <a id="groupsubgroupcreationlevel"></a>`subgroupCreationLevel` | [`String`](#string) | The permission level required to create subgroups within the group. |
@@ -11092,6 +11093,7 @@ Contains statistics about a milestone.
 | <a id="namespacerepositorysizeexcessprojectcount"></a>`repositorySizeExcessProjectCount` | [`Int!`](#int) | Number of projects in the root namespace where the repository size exceeds the limit. |
 | <a id="namespacerequestaccessenabled"></a>`requestAccessEnabled` | [`Boolean`](#boolean) | Indicates if users can request access to namespace. |
 | <a id="namespacerootstoragestatistics"></a>`rootStorageStatistics` | [`RootStorageStatistics`](#rootstoragestatistics) | Aggregated storage statistics of the namespace. Only available for root namespaces. |
+| <a id="namespacesharedrunnerssetting"></a>`sharedRunnersSetting` | [`SharedRunnersSetting`](#sharedrunnerssetting) | Shared runners availability for the namespace and its descendants. |
 | <a id="namespacestoragesizelimit"></a>`storageSizeLimit` | [`Float`](#float) | Total storage limit of the root namespace in bytes. |
 | <a id="namespacetemporarystorageincreaseendson"></a>`temporaryStorageIncreaseEndsOn` | [`Time`](#time) | Date until the temporary storage increase is active. |
 | <a id="namespacetotalrepositorysize"></a>`totalRepositorySize` | [`Float`](#float) | Total repository size of all projects in the root namespace in bytes. |
@@ -15367,6 +15369,14 @@ State of a Sentry error.
 | <a id="servicetypewebex_teams_service"></a>`WEBEX_TEAMS_SERVICE` | WebexTeamsService type. |
 | <a id="servicetypeyoutrack_service"></a>`YOUTRACK_SERVICE` | YoutrackService type. |
 
+### `SharedRunnersSetting`
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="sharedrunnerssettingdisabled_and_unoverridable"></a>`DISABLED_AND_UNOVERRIDABLE` | Sharing of runners is disabled and unoverridable. |
+| <a id="sharedrunnerssettingdisabled_with_override"></a>`DISABLED_WITH_OVERRIDE` | Sharing of runners is disabled with override. |
+| <a id="sharedrunnerssettingenabled"></a>`ENABLED` | Sharing of runners is enabled. |
+
 ### `SnippetBlobActionEnum`
 
 Type of a snippet blob input action.

doc/api/group_protected_environments.md

@@ -14,7 +14,7 @@ type: concepts, howto
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](../ci/environments/protected_environments.md#enable-or-disable-group-level-protected-environments). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Read more about [group-level protected environments](../ci/environments/protected_environments.md#group-level-protected-environments),

doc/api/index.md

@@ -254,7 +254,7 @@ tries to steal tokens from other jobs.
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-ci-job-token-scope-limit). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can limit the access scope of a project's CI/CD job token to increase the

doc/ci/environments/protected_environments.md

@@ -163,7 +163,7 @@ For more information, see [Deployment safety](deployment_safety.md).
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-group-level-protected-environments). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Typically, large enterprise organizations have an explicit permission boundary

doc/ci/pipelines/index.md

@@ -362,7 +362,7 @@ you visualize the entire pipeline, including all cross-project inter-dependencie
 > - To disable in GitLab self-managed instances, ask a GitLab administrator to [disable it](#enable-or-disable-job-dependency-view). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../user/feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can arrange jobs in the pipeline graph based on their [`needs`](../yaml/index.md#needs)

doc/ci/yaml/index.md

@@ -474,7 +474,7 @@ Use local includes instead of symbolic links.
 > - For GitLab self-managed instances, GitLab administrators can opt to disable it. **(CORE ONLY)**
 
 There can be
-[risks when disabling released features](../../user/feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 You can use wildcard paths (`*` and `**`) with `include:local`.

doc/development/documentation/feature_flags.md

@@ -8,7 +8,7 @@ description: "GitLab development - how to document features deployed behind feat
 
 # Document features deployed behind feature flags
 
-GitLab uses [Feature Flags](../feature_flags/index.md) to strategically roll
+GitLab uses [feature flags](../feature_flags/index.md) to strategically roll
 out the deployment of its own features. The way we document a feature behind a
 feature flag depends on its state (enabled or disabled). When the state
 changes, the developer who made the change **must update the documentation**
@@ -18,296 +18,85 @@ Every feature introduced to the codebase, even if it's behind a feature flag,
 must be documented. For context, see the
 [latest merge request that updated this guideline](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47917#note_459984428).
 
-## Criteria
+## Use a note to describe the state of the feature flag
 
-According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/):
+Information about feature flags should be in a **Note** at the start of the topic (just below the version history).
 
-> - _By default, feature flags should be off._
-> - _Feature flags should remain in the codebase for a short period as possible to reduce the need for feature flag accounting._
-> - _In order to build a final release and present the feature for self-managed users, the feature flag should be at least defaulted to on._
+The note has three parts, and follows this structure:
 
-See how to document them below, according to the state of the flag:
-
-- [Features disabled by default](#features-disabled-by-default).
-- [Features that became enabled by default](#features-that-became-enabled-by-default).
-- [Features directly enabled by default](#features-directly-enabled-by-default).
-- [Features that can be enabled or disabled for a single project](#features-enabled-by-project).
-- [Features with the feature flag removed](#features-with-flag-removed).
-
-The [`**(FREE SELF)**`](styleguide/index.md#product-tier-badges) badge or equivalent for
-the feature's tier should be added to the line and heading that refers to
-enabling/disabling feature flags as Admin access is required to do so,
-therefore, it indicates that it cannot be done by regular users of GitLab.com.
-
-### Features disabled by default
-
-For features disabled by default, add or improve the docs with every change in line with the
-[definition of done](../contributing/merge_request_workflow.md#definition-of-done).
-
-Include details of the feature flag in the documentation:
-
-- Say that it's disabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to enable and disable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
-
-For example, for a feature disabled by default, disabled on GitLab.com, cannot
-be enabled for a single project, and is not ready for production use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
-> - Disabled on GitLab.com.
-> - Not recommended for production use.
-> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#anchor-to-section). **(FREE SELF)**
-
-This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](<replace with path to>/user/feature_flags.md#risks-when-enabling-features-still-in-development).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
-
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development and not ready for production use. It is
-deployed behind a feature flag that is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can enable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
-```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`, and
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features that became enabled by default
-
-For features that were released disabled by default but became enabled by
-default:
-
-- Say that it became enabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to disable and enable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
-
-For example, for a feature initially deployed disabled by default, that became
-enabled by default, that is enabled on GitLab.com, and is ready for production
-use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), disabled by default.
-> - [Enabled by default](link-to-issue) in GitLab 12.1.
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
-
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
-
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
+```markdown
+NOTE:
+<Self-managed GitLab availability information.> <GitLab.com availability information.>
+<This feature is not ready for production use.>
 ```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
 
-### Features directly enabled by default
+### Self-managed GitLab availability information
 
-For features enabled by default:
+|If the feature is... | Use this text |
+|-|-|
+|Available|`On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable|`On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-group|`On self-managed GitLab, by default this feature is available. To hide the feature per group, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-group|`On self-managed GitLab, by default this feature is not available. To make it available per group, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-project|`On self-managed GitLab, by default this feature is available. To hide the feature per project or for your entire instance, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-project|`On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Available, per-user|`On self-managed GitLab, by default this feature is available. To hide the feature per user, ask an administrator to [disable the <flag name> flag](<path to>/administration/feature_flags.md).`|
+|Unavailable, per-user|`On self-managed GitLab, by default this feature is not available. To make it available per user, ask an administrator to [enable the <flag name> flag](<path to>/administration/feature_flags.md).`|
 
-- Say it's enabled by default.
-- Say whether it's enabled on GitLab.com.
-- If the feature can be enabled/disabled for a single project, add the
-  [by-project information](#features-enabled-by-project). Otherwise,
-  do not say anything about it.
-- Say whether it's recommended for production use.
-- Document how to disable and enable it, preferably at the end of the file.
-- Add a warning to the user saying that the feature might be disabled.
+### GitLab.com availability information
 
-For example, for a feature enabled by default, enabled on GitLab.com, that
-cannot be enabled for a single project, and is ready for production use:
+|If the feature is... | Use this text |
+|-|-|
+|Available| `On GitLab SaaS, this feature is available.` |
+|Unavailable| `On GitLab SaaS, this feature is not available.`|
 
-````markdown
-# Feature Name
+### Optional information
 
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
+If needed, you can add this sentence:
 
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
+`You should not use this feature for production environments.`
 
-(...Regular content goes here...)
+## Add version history text
 
-<!-- Add this at the end of the file -->
+When the state of a flag changes (for example, disabled by default to enabled by default), add the change to the version history.
 
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:<feature flag>)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:<feature flag>)
-```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features enabled by project
-
-If the feature can be enabled/disabled for a single project, include in the
-version history note:
+Possible version history entries are:
 
 ```markdown
-> - It can be enabled or disabled for a single project.
+> - [Enabled for GitLab.com](issue-link) in GitLab X.X and is ready for production use.
+> - [Enabled with <flag name> flag](issue-link) for self-managed GitLab in GitLab X.X and is ready for production use.
+> - [Feature flag <flag name> removed](issue-line) in GitLab X.X.
 ```
 
-Then add the by-project code to the code blocks:
+## Feature flag documentation examples
 
-Enable code:
-
-```ruby
-# For the instance
-Feature.enable(:<feature flag>)
-# For a single project
-Feature.enable(:<feature flag>, Project.find(<project id>))
-```
+The following examples show the progression of a feature flag.
 
-Disable code:
+```markdown
+> Introduced in GitLab 13.7.
 
-```ruby
-# For the instance
-Feature.disable(:<feature flag>)
-# For a single project
-Feature.disable(:<feature flag>, Project.find(<project id>))
+NOTE:
+On self-managed GitLab, by default this feature is not available. To make it available,
+ask an administrator to [enable the `forti_token_cloud` flag](../administration/feature_flags.md).`
+The feature is not ready for production use.
 ```
 
-For example, for a feature enabled by default, enabled on GitLab.com, that can
-be enabled by project, and is ready for production use:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Deployed behind a feature flag](<replace with path to>/user/feature_flags.md), enabled by default.
-> - Enabled on GitLab.com.
-> - Can be enabled or disabled for a single project.
-> - Recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#anchor-to-section). **(FREE SELF)**
-
-There can be
-[risks when disabling released features](<replace with path to>/user/feature_flags.md#risks-when-disabling-released-features).
-Refer to this feature's version history for more details.
-
-(...Regular content goes here...)
+If it were to be updated in the future to enable its use in production, you can update the version history:
 
-<!-- Add this at the end of the file -->
-
-### Enable or disable <Feature Name> **(FREE SELF)**
-
-<Feature Name> is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](<replace with path to>/administration/feature_flags.md)
-can opt to disable it.
-
-To enable it:
+```markdown
+> - Introduced in GitLab 13.7.
+> - [Enabled with `forti_token_cloud` flag](https://gitlab.com/issue/etc) for self-managed GitLab in GitLab X.X and ready for production use.
 
-```ruby
-# For the instance
-Feature.enable(:<feature flag>)
-# For a single project
-Feature.enable(:<feature flag>, Project.find(<project id>))
+NOTE:
+On self-managed GitLab, by default this feature is available. To hide the feature per user,
+ask an administrator to [disable the `forti_token_cloud` flag](../administration/feature_flags.md).
 ```
 
-To disable it:
+And, when the feature is done and fully available to all users:
 
-```ruby
-# For the instance
-Feature.disable(:<feature flag>)
-# For a single project
-Feature.disable(:<feature flag>, Project.find(<project id>))
+```markdown
+> - Introduced in GitLab 13.7.
+> - [Enabled for GitLab.com](https://gitlab.com/issue/etc) in GitLab X.X and is ready for production use.
+> - [Enabled with `forti_token_cloud` flag](https://gitlab.com/issue/etc) for self-managed GitLab in GitLab X.X and is ready for production use.
+> - [Feature flag `forti_token_cloud`](https://gitlab.com/issue/etc) removed in GitLab X.X.
 ```
-````
-
-Adjust the blurb according to the state of the feature you're documenting.
-Replace `<Feature name>`, `**(FREE SELF)**`, `<feature flag>`,
-`<replace with path to>`, and `#anchor-to-section` accordingly.
-
-### Features with flag removed
-
-Once the feature is ready and the flag has been removed, clean up the
-documentation. Remove the feature flag mention keeping only a note that
-mentions the flag in the version history notes:
-
-````markdown
-# Feature Name
-
-> - [Introduced](link-to-issue) in GitLab 12.0.
-> - [Feature flag removed](link-to-issue) in GitLab 12.2.
-
-(...Regular content...)
-
-````

doc/development/documentation/styleguide/word_list.md

@@ -175,7 +175,7 @@ Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#v
 
 ## in order to
 
-Do not use. Use **to** instead.
+Do not use. Use **to** instead. ([Vale](../testing.md#vale) rule: [`Wordy.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/Wordy.yml))
 
 ## issue
 

doc/development/i18n/proofreader.md

@@ -28,6 +28,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Huang Tao - [GitLab](https://gitlab.com/htve), [CrowdIn](https://crowdin.com/profile/htve)
   - Victor Wu - [GitLab](https://gitlab.com/victorwuky), [CrowdIn](https://crowdin.com/profile/victorwu)
   - Xiaogang Wen - [GitLab](https://gitlab.com/xiaogang_gitlab), [CrowdIn](https://crowdin.com/profile/xiaogang_gitlab)
+  - Shuang Zhang - [GitLab](https://gitlab.com/tonygodspeed92), [CrowdIn](https://crowdin.com/profile/tonygodspeed92)
 - Chinese Traditional 繁體中文
   - Weizhe Ding - [GitLab](https://gitlab.com/d.weizhe), [CrowdIn](https://crowdin.com/profile/d.weizhe)
   - Yi-Jyun Pan - [GitLab](https://gitlab.com/pan93412), [CrowdIn](https://crowdin.com/profile/pan93412)

doc/topics/autodevops/quick_start_guide.md

@@ -4,19 +4,30 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Getting started with Auto DevOps **(FREE)**
+# Tutorial: Use Auto DevOps to deploy an application to Google Kubernetes Engine **(FREE)**
 
 This step-by-step guide helps you use [Auto DevOps](index.md) to
-deploy a project hosted on GitLab.com to Google Kubernetes Engine.
+In this tutorial, we'll help you to get started with [Auto DevOps](index.md)
+through an example of how to deploy an application to Google Kubernetes Engine (GKE).
 
 You are using the GitLab native Kubernetes integration, so you don't need
 to create a Kubernetes cluster manually using the Google Cloud Platform console.
-You are creating and deploying a simple application that you create from a GitLab template.
+You are creating and deploying an application that you create from a GitLab template.
 
-These instructions also work for a self-managed GitLab instance;
-ensure your own [runners are configured](../../ci/runners/index.md) and
+These instructions also work for self-managed GitLab instances.
+Ensure your own [runners are configured](../../ci/runners/index.md) and
 [Google OAuth is enabled](../../integration/google.md).
 
+To deploy a project to Google Kubernetes Engine, follow the steps below:
+
+1. [Configure your Google account](#configure-your-google-account)
+1. [Create a new project from a template](#create-a-new-project-from-a-template)
+1. [Create a Kubernetes cluster from GitLab](#create-a-kubernetes-cluster-from-gitlab)
+1. [Install Ingress](#install-ingress)
+1. [Configure your base domain](#configure-your-base-domain)
+1. [Enable Auto DevOps](#enable-auto-devops-optional)
+1. [Deploy the application](#deploy-the-application)
+
 ## Configure your Google account
 
 Before creating and connecting your Kubernetes cluster to your GitLab project,
@@ -38,12 +49,12 @@ and apply for credit.
 
 ## Create a new project from a template
 
-We are using a GitLab project template to get started. As the name suggests,
+Use a GitLab project template to get started. As the name suggests,
 those projects provide a bare-bones application built on some well-known frameworks.
 
-1. In GitLab, click the plus icon (**{plus-square}**) at the top of the navigation bar, and select
-   **New project**.
-1. Go to the **Create from template** tab, where you can choose among a Ruby on
+1. On the top bar in GitLab, select the plus icon (**{plus-square}**), and select
+   **New project/repository**.
+1. Go to the **Create from template** tab, where you can choose a Ruby on
    Rails, Spring, or NodeJS Express project.
    For this tutorial, use the Ruby on Rails template.
 
@@ -55,23 +66,21 @@ those projects provide a bare-bones application built on some well-known framewo
 
    ![Create project](img/guide_create_project_v12_3.png)
 
-1. Click **Create project**.
+1. Select **Create project**.
 
 Now that you've created a project, create the Kubernetes cluster
 to deploy this project to.
 
-## Create a Kubernetes cluster from within GitLab
+## Create a Kubernetes cluster from GitLab
 
-1. On your project's landing page, click **Add Kubernetes cluster**
-   (note that this option is also available when you navigate to
-   **Infrastructure > Kubernetes clusters**).
+1. On your project's landing page, select the button **Add Kubernetes cluster**.
 
    ![Project landing page](img/guide_project_landing_page_v12_10.png)
 
-1. On the **Add a Kubernetes cluster integration** page, click the **Create new cluster** tab,
-   then click **Google GKE**.
+1. On the **Add a Kubernetes cluster integration** page, select the **Create new cluster** tab,
+   then select **Google GKE**.
 
-1. Connect with your Google account, and click **Allow** to allow access to your
+1. Connect with your Google account, and select **Allow** to allow access to your
    Google account. (This authorization request is only displayed the first time
    you connect GitLab with your Google account.)
 
@@ -97,7 +106,7 @@ to deploy this project to.
    - **GitLab-managed cluster** - Select this checkbox to
      [allow GitLab to manage namespace and service accounts](../../user/project/clusters/index.md#gitlab-managed-clusters) for this cluster.
 
-1. Click **Create Kubernetes cluster**.
+1. Select **Create Kubernetes cluster**.
 
 After a couple of minutes, the cluster is created. You can also see its
 status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
@@ -105,14 +114,14 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 ## Install Ingress
 
 After your cluster is running, you must install NGINX Ingress Controller as a
-load balancer, to route traffic from the internet to your application. Because
-you've created a Google GKE cluster in this guide, you can install NGINX Ingress Controller
+load balancer, to route traffic from the internet to your application.
+Install the NGINX Ingress Controller
 through the GitLab [Cluster management project template](../../user/clusters/management_project_template.md),
 or manually with Google Cloud Shell:
 
-1. Go to your cluster's details page, and click the **Advanced Settings** tab.
-1. Click the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console.
-1. On the GKE cluster page, select **Connect**, then click **Run in Cloud Shell**.
+1. Go to your cluster's details page, and select the **Advanced Settings** tab.
+1. Select the link to Google Kubernetes Engine to visit the cluster on Google Cloud Console.
+1. On the GKE cluster page, select **Connect**, then select **Run in Cloud Shell**.
 1. After the Cloud Shell starts, run these commands to install NGINX Ingress Controller:
 
    ```shell
@@ -127,7 +136,7 @@ or manually with Google Cloud Shell:
 
 ## Configure your base domain
 
-Follow these steps to configure the Base Domain where your apps will be accessible.
+Follow these steps to configure the base domain where you access your apps.
 
 1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can
    get the external IP address with the following command:
@@ -141,8 +150,8 @@ Follow these steps to configure the Base Domain where your apps will be accessib
    Copy this IP address, as you need it in the next step.
 
 1. Go back to the cluster page on GitLab, and go to the **Details** tab.
-   - Add your **Base domain**. For this guide, use the domain `<IP address>.nip.io`.
-   - Click **Save changes**.
+   - Add your **Base domain**. For this example, use the domain `<IP address>.nip.io`.
+   - Select **Save changes**.
 
    ![Cluster Base Domain](img/guide_base_domain_v12_3.png)
 
@@ -152,11 +161,11 @@ While Auto DevOps is enabled by default, Auto DevOps can be disabled at both
 the instance level (for self-managed instances) and the group level. Complete
 these steps to enable Auto DevOps if it's disabled:
 
-1. Navigate to **Settings > CI/CD > Auto DevOps**, and click **Expand**.
+1. Go to **Settings > CI/CD > Auto DevOps**, and select **Expand**.
 1. Select **Default to Auto DevOps pipeline** to display more options.
 1. In **Deployment strategy**, select your desired [continuous deployment strategy](requirements.md#auto-devops-deployment-strategy)
    to deploy the application to production after the pipeline successfully runs on the default branch.
-1. Click **Save changes**.
+1. Select **Save changes**.
 
    ![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
 
@@ -169,7 +178,7 @@ In the next section, we explain what each job does in the pipeline.
 
 When your pipeline runs, what is it doing?
 
-To view the jobs in the pipeline, click the pipeline's status badge. The
+To view the jobs in the pipeline, select the pipeline's status badge. The
 **{status_running}** icon displays when pipeline jobs are running, and updates
 without refreshing the page to **{status_success}** (for success) or
 **{status_failed}** (for failure) when the jobs complete.
@@ -238,7 +247,7 @@ you to common environment tasks:
 GitLab displays the [Deploy Board](../../user/project/deploy_boards.md) below the
 environment's information, with squares representing pods in your
 Kubernetes cluster, color-coded to show their status. Hovering over a square on
-the deploy board displays the state of the deployment, and clicking the square
+the deploy board displays the state of the deployment, and selecting the square
 takes you to the pod's logs page.
 
 NOTE:
@@ -251,7 +260,7 @@ in **Settings > CI/CD > Variables**.
 Following the [GitLab flow](../gitlab_flow.md#working-with-feature-branches),
 you should next create a feature branch to add content to your application:
 
-1. In your project's repository, navigate to the following file: `app/views/welcome/index.html.erb`.
+1. In your project's repository, go to the following file: `app/views/welcome/index.html.erb`.
    This file should only contain a paragraph: `<p>You're on Rails!</p>`.
 1. Open the GitLab [Web IDE](../../user/project/web_ide/index.md) to make the change.
 1. Edit the file so it contains:
@@ -261,7 +270,7 @@ you should next create a feature branch to add content to your application:
    ```
 
 1. Stage the file. Add a commit message, then create a new branch and a merge request
-   by clicking **Commit**.
+   by selecting **Commit**.
 
    ![Web IDE commit](img/guide_ide_commit_v12_3.png)
 
@@ -272,7 +281,7 @@ a few more that run only on branches other than the default branch.
 ![Merge request](img/guide_merge_request_v12_3.png)
 
 After a few minutes a test fails, which means a test was
-'broken' by your change. Click on the failed `test` job to see more information
+'broken' by your change. Select the failed `test` job to see more information
 about it:
 
 ```plaintext
@@ -287,18 +296,18 @@ bin/rails test test/controllers/welcome_controller_test.rb:4
 
 To fix the broken test:
 
-1. Return to the **Overview** page for your merge request, and click **Open in Web IDE**.
+1. Return to the **Overview** page for your merge request, and select **Open in Web IDE**.
 1. In the left-hand directory of files, find the `test/controllers/welcome_controller_test.rb`
-   file, and click it to open it.
+   file, and select it to open it.
 1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
-1. Click **Commit**.
-1. In the left-hand column, under **Unstaged changes**, click the checkmark icon
+1. Select **Commit**.
+1. In the left-hand column, under **Unstaged changes**, select the checkmark icon
    (**{stage-all}**) to stage the changes.
-1. Write a commit message, and click **Commit**.
+1. Write a commit message, and select **Commit**.
 
 Return to the **Overview** page of your merge request, and you should not only
 see the test passing, but also the application deployed as a
-[review application](stages.md#auto-review-apps). You can visit it by clicking
+[review application](stages.md#auto-review-apps). You can visit it by selecting
 the **View app** **{external-link}** button to see your changes deployed.
 
 ![Review app](img/guide_merge_request_review_app_v12_3.png)

doc/user/admin_area/monitoring/background_migrations.md

@@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - Recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations). **(FREE SELF)**
 
-There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To update database tables in batches, GitLab can use batched background migrations. These migrations
@@ -54,7 +54,7 @@ Feature.disable(:execute_batched_migrations_on_schedule)
 > - Recommended for production use.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-automatic-batch-size-optimization). **(FREE SELF)**
 
-There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+There can be [risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To maximize throughput of batched background migrations (in terms of the number of tuples updated per time unit), batch sizes are automatically adjusted based on how long the previous batches took to complete.

doc/user/application_security/dependency_scanning/index.md

@@ -125,7 +125,7 @@ WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 
 There can be
-[risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 To enable Dependency Scanning in a project, you can create a merge request

doc/user/feature_flags.md

@@ -20,21 +20,13 @@ may be unavailable to you.
 In this case, you'll see a warning like this in the feature documentation:
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 In the version history note, you'll find information on the state of the
 feature flag, including whether the feature is on ("enabled by default") or
 off ("disabled by default") for self-managed GitLab instances and for users of
-GitLab.com. To see the full notes:
-
-1. Click the three-dots icon (ellipsis) to expand version history notes:
-
-   ![Version history note with FF information](img/version_history_notes_collapsed_v13_2.png)
-
-1. Read the version history information:
-
-   ![Version history note with FF information](img/feature_flags_history_note_info_v13_2.png)
+GitLab.com.
 
 If you're a user of a GitLab self-managed instance and you want to try to use a
 disabled feature, you can ask a [GitLab administrator to enable it](../administration/feature_flags.md),
@@ -42,17 +34,3 @@ although changing a feature's default state isn't recommended.
 
 If you're a GitLab.com user and the feature is disabled, be aware that GitLab may
 be working on the feature for potential release in the future.
-
-## Risks when enabling features still in development
-
-Features that are disabled by default may change or be removed without notice in a future version of GitLab.
-
-Data corruption, stability degradation, or performance degradation might occur if
-you enable a feature that's disabled by default. Problems caused by using a default
-disabled feature aren't covered by GitLab support, unless you were directed by GitLab
-to enable the feature.
-
-## Risks when disabling released features
-
-In most cases, the feature flag code is removed in a future version of GitLab.
-If and when that occurs, from that point onward you can't keep the feature in a disabled state.

doc/user/group/import/index.md

@@ -11,8 +11,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Deployed behind a feature flag](../../feature_flags.md), disabled by default.
 > - Enabled on GitLab.com.
 
-WARNING:
-This feature is [under construction](https://gitlab.com/groups/gitlab-org/-/epics/2771), and migrates only some of the group data. Refer to the following information for the list of what's included in the migration.
+NOTE:
+The importer migrates **only** the group data listed on this page. To leave feedback on this
+feature, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/284495).
 
 Using GitLab Group Migration, you can migrate existing top-level groups from GitLab.com or a self-managed instance. Groups can be migrated to a target instance, as a top-level group, or as a subgroup of any existing top-level group.
 

doc/user/group/iterations/index.md

@@ -41,7 +41,7 @@ In GitLab, iterations are similar to milestones, with a few differences:
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-iteration-cadences). **(PREMIUM SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 Iteration cadences automate some common iteration tasks. They can be used to

doc/user/project/issue_board.md

@@ -233,7 +233,7 @@ and vice versa.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-graphql-based-issue-boards). **(FREE SELF)**
 
 There can be
-[risks when disabling released features](../feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 Using GraphQL-based boards gives you these
@@ -345,7 +345,7 @@ As in other list types, click the trash icon to remove a list.
 > - For GitLab self-managed instances, GitLab administrators can opt to disable the feature flags: [`board_new_list`](#enable-or-disable-new-add-list-form) and [`iteration_board_lists`](#enable-or-disable-iteration-lists-in-boards). **(PREMIUM SELF)**
 
 There can be
-[risks when disabling released features](../feature_flags.md#risks-when-disabling-released-features).
+[risks when disabling released features](../../administration/feature_flags.md#risks-when-disabling-released-features).
 Refer to this feature's version history for more details.
 
 You're also able to create lists of an iteration.
@@ -629,7 +629,7 @@ and the target list.
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-multi-selecting-issue-cards). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 You can select multiple issue cards, then drag the group to another position within the list, or to

doc/user/project/merge_requests/changes.md

@@ -140,7 +140,7 @@ Feature.disable(:local_file_reviews)
 > - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-merge-request-conflicts-in-diff). **(FREE SELF)**
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 To avoid displaying the changes that are already on target branch in the diff,

doc/user/project/merge_requests/commits.md

@@ -42,7 +42,7 @@ Previously merged commits can be added, but they can't be removed due to
 [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/325538).
 
 This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../feature_flags.md#risks-when-enabling-features-still-in-development).
+[risks when enabling features still in development](../../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
 Refer to this feature's version history for more details.
 
 When reviewing a merge request, it helps to have more context about the changes

ee/spec/config/metrics/every_metric_definition_spec.rb

@@ -11,7 +11,6 @@ RSpec.describe 'Every metric definition' do
       geo_node_usage
       license_add_ons
       testing_total_unique_counts
-      topology
       user_auth_by_provider
     ).freeze
   end
@@ -19,7 +18,7 @@ RSpec.describe 'Every metric definition' do
   let(:usage_ping_key_paths) do
     parse_usage_ping_keys(usage_ping)
       .flatten
-      .reject { |v| v =~ Regexp.union(ignored_usage_ping_key_patterns)}
+      .reject { |v| v =~ Regexp.union(ignored_usage_ping_key_patterns) }
       .sort
   end
 
@@ -29,7 +28,6 @@ RSpec.describe 'Every metric definition' do
       geo_node_usage
       mock_ci
       mock_monitoring
-      projects_with_enabled_alert_integrations_histogram
       user_auth_by_provider
       user_dast_scans
       user_sast_scans
@@ -38,22 +36,27 @@ RSpec.describe 'Every metric definition' do
       user_secret_detection_scans
       user_coverage_fuzzing_scans
       user_api_fuzzing_scans
-      topology
     ).freeze
   end
 
   let(:metric_files_key_paths) do
     Gitlab::Usage::MetricDefinition
       .definitions
-      .reject { |k, v| v.status == 'removed' || v.key_path =~ Regexp.union(ignored_metric_files_key_patterns)}
+      .reject { |k, v| v.status == 'removed' || v.key_path =~ Regexp.union(ignored_metric_files_key_patterns) }
       .keys
       .sort
   end
 
+  let(:metric_files_with_schema) do
+    Gitlab::Usage::MetricDefinition
+      .definitions
+      .select { |k, v| v.respond_to?(:value_json_schema) }
+  end
+
   # Recursively traverse nested Hash of a generated Usage Ping to return an Array of key paths
   # in the dotted format used in metric definition YAML files, e.g.: 'count.category.metric_name'
   def parse_usage_ping_keys(object, key_path = [])
-    if object.is_a? Hash
+    if object.is_a?(Hash) && !object_with_schema?(key_path.join('.'))
       object.each_with_object([]) do |(key, value), result|
         result.append parse_usage_ping_keys(value, key_path + [key])
       end
@@ -62,6 +65,10 @@ RSpec.describe 'Every metric definition' do
     end
   end
 
+  def object_with_schema?(key_path)
+    metric_files_with_schema.key?(key_path)
+  end
+
   before do
     allow(Gitlab::UsageData).to receive_messages(count: -1, distinct_count: -1, estimate_batch_distinct_count: -1, sum: -1, alt_usage_data: -1)
     allow(Gitlab::Geo).to receive(:enabled?).and_return(true)
@@ -73,4 +80,14 @@ RSpec.describe 'Every metric definition' do
   it 'is included in the Usage Ping hash structure' do
     expect(metric_files_key_paths).to match_array(usage_ping_key_paths)
   end
+
+  context 'with value json schema' do
+    it 'has a valid structure', :aggregate_failures do
+      metric_files_with_schema.each do |key_path, metric|
+        structure = usage_ping.dig(*key_path.split('.').map(&:to_sym))
+
+        expect(structure).to match_metric_definition_schema(metric.value_json_schema)
+      end
+    end
+  end
 end

lib/gitlab/usage/metric_definition.rb

@@ -114,6 +114,10 @@ module Gitlab
         attributes[method] || super
       end
 
+      def respond_to_missing?(method, *args)
+        attributes[method].present? || super
+      end
+
       def skip_validation?
         !!attributes[:skip_validation] || @skip_validation || SKIP_VALIDATION_STATUSES.include?(attributes[:status])
       end

lib/gitlab/usage/metrics/instrumentations/collected_data_categories_metric.rb

@@ -6,7 +6,7 @@ module Gitlab
       module Instrumentations
         class CollectedDataCategoriesMetric < GenericMetric
           value do
-            ::ServicePing::PermitDataCategoriesService.new.execute
+            ::ServicePing::PermitDataCategoriesService.new.execute.to_a
           end
         end
       end

spec/graphql/types/group_type_spec.rb

@@ -18,7 +18,7 @@ RSpec.describe GitlabSchema.types['Group'] do
       two_factor_grace_period auto_devops_enabled emails_disabled
       mentions_disabled parent boards milestones group_members
       merge_requests container_repositories container_repositories_count
-      packages
+      packages shared_runners_setting
     ]
 
     expect(described_class).to include_graphql_fields(*expected_fields)

spec/graphql/types/namespace_type_spec.rb

@@ -8,7 +8,7 @@ RSpec.describe GitlabSchema.types['Namespace'] do
   it 'has the expected fields' do
     expected_fields = %w[
       id name path full_name full_path description description_html visibility
-      lfs_enabled request_access_enabled projects root_storage_statistics
+      lfs_enabled request_access_enabled projects root_storage_statistics shared_runners_setting
     ]
 
     expect(described_class).to include_graphql_fields(*expected_fields)

spec/requests/api/graphql/group_query_spec.rb

@@ -78,6 +78,7 @@ RSpec.describe 'getting group information' do
         expect(graphql_data['group']['parentId']).to eq(group1.parent_id)
         expect(graphql_data['group']['issues']['nodes'].count).to eq(1)
         expect(graphql_data['group']['issues']['nodes'][0]['iid']).to eq(issue.iid.to_s)
+        expect(graphql_data['group']['sharedRunnersSetting']).to eq(group1.shared_runners_setting.upcase)
       end
 
       it "does not return a non existing group" do

spec/support/matchers/schema_matcher.rb

@@ -45,6 +45,17 @@ RSpec::Matchers.define :match_response_schema do |schema, dir: nil, **options|
   end
 end
 
+RSpec::Matchers.define :match_metric_definition_schema do |path, dir: nil, **options|
+  match do |data|
+    schema_path = Pathname.new(Rails.root.join(dir.to_s, path).to_s)
+    validator = SchemaPath.validator(schema_path)
+
+    data = data.stringify_keys if data.is_a? Hash
+
+    validator.valid?(data)
+  end
+end
+
 RSpec::Matchers.define :match_snowplow_schema do |schema, dir: nil, **options|
   match do |data|
     schema_path = Pathname.new(Rails.root.join(dir.to_s, 'spec', "fixtures/product_intelligence/#{schema}.json").to_s)