Merge branch 'rename-file-paths' into 'master'

Rename file path and add change links

See merge request gitlab-org/gitlab!65814

app/views/admin/application_settings/_usage.html.haml

@@ -32,7 +32,7 @@
             %pre.service-data-payload-container.js-syntax-highlight.code.highlight.mt-2.d-none{ class: payload_class, data: { endpoint: usage_data_admin_application_settings_path(format: :html) } }
           - else
             = _('Service ping is disabled, and cannot be configured through this form.')
-            - deactivating_service_ping_path = help_page_path('development/usage_ping/index.md', anchor: 'disable-service-ping')
+            - deactivating_service_ping_path = help_page_path('development/service_ping/index.md', anchor: 'disable-service-ping')
             - deactivating_service_ping_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: deactivating_service_ping_path }
             = s_('For more information, see the documentation on %{deactivating_service_ping_link_start}deactivating service ping%{deactivating_service_ping_link_end}.').html_safe % { deactivating_service_ping_link_start: deactivating_service_ping_link_start, deactivating_service_ping_link_end: '</a>'.html_safe }
     .form-group
@@ -41,7 +41,7 @@
         = f.check_box :usage_ping_features_enabled?, disabled: !usage_ping_enabled, class: 'form-check-input'
         = f.label :usage_ping_features_enabled?, class: 'form-check-label gl-cursor-not-allowed', id: 'usage_ping_features_label' do
           = _('Enable Registration Features')
-          = link_to sprite_icon('question-o'), help_page_path('development/usage_ping/index.md', anchor: 'registration-features-program')
+          = link_to sprite_icon('question-o'), help_page_path('development/service_ping/index.md', anchor: 'registration-features-program')
         .form-text.text-muted
           - if usage_ping_enabled
             %p.gl-mb-3.text-muted{ id: 'usage_ping_features_helper_text' }= _('You can enable Registration Features because Service Ping is enabled. To continue using Registration Features in the future, you will also need to register with GitLab via a new cloud licensing service.')

doc/api/usage_data.md

@@ -7,7 +7,7 @@ type: reference, api
 
 # Service Data API **(FREE SELF)**
 
-The Service Data API is associated with [Service Ping](../development/usage_ping/index.md).
+The Service Data API is associated with [Service Ping](../development/service_ping/index.md).
 
 ## Export metric definitions as a single YAML file
 

doc/development/index.md

@@ -304,7 +304,7 @@ See [database guidelines](database/index.md).
 ## Product Intelligence guides
 
 - [Product Intelligence guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Service Ping guide](usage_ping/index.md)
+- [Service Ping guide](service_ping/index.md)
 - [Snowplow guide](snowplow/index.md)
 
 ## Experiment guide

doc/development/query_performance.md

@@ -21,7 +21,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 | Queries in a migration | `100ms` | This is different than the total [migration time](database_review.md#timing-guidelines-for-migrations). |
 | Concurrent operations in a migration | `5min` | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. |
 | Background migrations | `1s` |  |
-| Service Ping | `1s` | See the [Service Ping docs](usage_ping/index.md#developing-and-testing-service-ping) for more details. |
+| Service Ping | `1s` | See the [Service Ping docs](service_ping/index.md#developing-and-testing-service-ping) for more details. |
 
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.

doc/development/service_ping/metrics_instrumentation.md

+---
+stage: Growth
+group: Product Intelligence
+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
+---
+
+# Metrics instrumentation guide
+
+This guide describes how to develop Service Ping metrics using metrics instrumentation.
+
+## Nomenclature
+
+- **Instrumentation class**:
+  - Inherits one of the metric classes: `DatabaseMetric`, `RedisHLLMetric` or `GenericMetric`.
+  - Implements the logic that calculates the value for a Service Ping metric.
+
+- **Metric definition**
+  The Service Data metric YAML definition.
+
+- **Hardening**:
+  Hardening a method is the process that ensures the method fails safe, returning a fallback value like -1.
+
+## How it works
+
+A metric definition has the [`instrumentation_class`](metrics_dictionary.md) field, which can be set to a class.
+
+The defined instrumentation class should have one of the existing metric classes: `DatabaseMetric`, `RedisHLLMetric`, or `GenericMetric`.
+
+Using the instrumentation classes ensures that metrics can fail safe individually, without breaking the entire
+ process of Service Ping generation.
+
+We have built a domain-specific language (DSL) to define the metrics instrumentation.
+
+## Database metrics
+
+[Example of a merge request that adds a database metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60022).
+
+```ruby
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class CountBoardsMetric < DatabaseMetric
+          operation :count
+
+          relation { Board }
+        end
+      end
+    end
+  end
+end
+```
+
+## Redis HyperLogLog metrics
+
+[Example of a merge request that adds a `RedisHLL` metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61685).
+
+Count unique values for `i_quickactions_approve` event.
+
+```yaml
+time_frame: 28d
+data_source: redis_hll
+instrumentation_class: 'Gitlab::Usage::Metrics::Instrumentations::RedisHLLMetric'
+options:
+  events:
+    - i_quickactions_approve
+```
+
+## Generic metrics
+
+[Example of a merge request that adds a generic metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60256).
+
+```ruby
+module Gitlab
+  module Usage
+    module Metrics
+      module Instrumentations
+        class UuidMetric < GenericMetric
+          value do
+            Gitlab::CurrentSettings.uuid
+          end
+        end
+      end
+    end
+  end
+end
+```
+
+## Creating a new metric instrumentation class
+
+To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
+
+The generator takes the class name as an argument and the following options:
+
+- `--type=TYPE` Required. Indicates the metric type. It must be one of: `database`, `generic`, `redis_hll`.
+- `--ee` Indicates if the metric is for EE.
+
+```shell
+rails generate gitlab:usage_metric CountIssues --type database
+        create lib/gitlab/usage/metrics/instrumentations/count_issues_metric.rb
+        create spec/lib/gitlab/usage/metrics/instrumentations/count_issues_metric_spec.rb
+```

doc/development/service_ping/review_guidelines.md

+---
+stage: Growth
+group: Product Intelligence
+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
+---
+
+# Service Ping review guidelines
+
+This page includes introductory material for a
+[Product Intelligence](https://about.gitlab.com/handbook/engineering/development/growth/product-intelligence/)
+review, and is specific to Service Ping related reviews. For broader advice and
+general best practices for code reviews, refer to our [code review guide](../code_review.md).
+
+## Resources for reviewers
+
+- [Service Ping Guide](index.md)
+- [Metrics Dictionary](metrics_dictionary.md)
+
+## Review process
+
+We recommend a Product Intelligence review when a merge request (MR) touches
+any of the following Service Ping files:
+
+- `usage_data*` files.
+- The Metrics Dictionary, including files in:
+  - [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics).
+  - [`ee/config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/metrics).
+  - [`dictionary.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/usage_ping/dictionary.md).
+  - [`schema.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
+- Product Intelligence tooling. For example,
+  [`Gitlab::UsageMetricDefinitionGenerator`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb)
+
+### Roles and process
+
+#### The merge request **author** should
+
+- Decide whether a Product Intelligence review is needed.
+- If a Product Intelligence review is needed, add the labels
+  `~product intelligence` and `~product intelligence::review pending`.
+- Assign an
+  [engineer](https://gitlab.com/groups/gitlab-org/growth/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) from the Product Intelligence team for a review.
+- Set the correct attributes in the metric's YAML definition:
+  - `product_section`, `product_stage`, `product_group`, `product_category`
+  - Provide a clear description of the metric.
+- Update the
+  [Metrics Dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/usage_ping/dictionary.md) if needed.
+- Add a changelog [according to guidelines](../changelog.md).
+
+#### The Product Intelligence **reviewer** should
+
+- Perform a first-pass review on the merge request and suggest improvements to the author.
+- Check the [metrics location](index.md#1-naming-and-placing-the-metrics) in
+  the Service Ping JSON payload.
+- Add the `~database` label and ask for a [database review](../database_review.md) for
+  metrics that are based on Database.
+- For tracking using Redis HLL (HyperLogLog):
+  - Check the Redis slot.
+  - Check if a [feature flag is needed](index.md#recommendations).
+- For a metric's YAML definition:
+  - Check the metric's `description`.
+  - Check the metric's `key_path`.
+  - Check the `product_section`, `product_stage`, `product_group`, and `product_category` fields.
+    Read the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
+  - Check the file location. Consider the time frame, and if the file should be under `ee`.
+  - Check the tiers.
+- Approve the MR, and relabel the MR with `~"product intelligence::approved"`.
+
+## Review workload distribution
+
+[Danger bot](../dangerbot.md) adds the list of changed Product Intelligence files
+and pings the
+[`@gitlab-org/growth/product-intelligence/engineers`](https://gitlab.com/groups/gitlab-org/growth/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) group for merge requests
+that are not drafts.
+
+Any of the Product Intelligence engineers can be assigned for the Product Intelligence review.

doc/development/snowplow/index.md

@@ -11,7 +11,7 @@ This guide provides an overview of how Snowplow works, and implementation detail
 For more information about Product Intelligence, see:
 
 - [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Service Ping Guide](../usage_ping/index.md)
+- [Service Ping Guide](../service_ping/index.md)
 
 More useful links:
 

doc/development/usage_ping/metrics_instrumentation.md

 ---
-stage: Growth
-group: Product Intelligence
-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
+redirect_to: '../service_ping/metrics_instrumentation.md'
+remove_date: '2021-10-09'
 ---
 
-# Metrics instrumentation guide
+This file was moved to [another location](../service_ping/metrics_instrumentation.md).
 
-This guide describes how to develop Service Ping metrics using metrics instrumentation.
-
-## Nomenclature
-
-- **Instrumentation class**:
-  - Inherits one of the metric classes: `DatabaseMetric`, `RedisHLLMetric` or `GenericMetric`.
-  - Implements the logic that calculates the value for a Service Ping metric.
-
-- **Metric definition**
-  The Service Data metric YAML definition.
-
-- **Hardening**:
-  Hardening a method is the process that ensures the method fails safe, returning a fallback value like -1.
-
-## How it works
-
-A metric definition has the [`instrumentation_class`](metrics_dictionary.md) field, which can be set to a class.
-
-The defined instrumentation class should have one of the existing metric classes: `DatabaseMetric`, `RedisHLLMetric`, or `GenericMetric`.
-
-Using the instrumentation classes ensures that metrics can fail safe individually, without breaking the entire
- process of Service Ping generation.
-
-We have built a domain-specific language (DSL) to define the metrics instrumentation.
-
-## Database metrics
-
-[Example of a merge request that adds a database metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60022).
-
-```ruby
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class CountBoardsMetric < DatabaseMetric
-          operation :count
-
-          relation { Board }
-        end
-      end
-    end
-  end
-end
-```
-
-## Redis HyperLogLog metrics
-
-[Example of a merge request that adds a `RedisHLL` metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61685).
-
-Count unique values for `i_quickactions_approve` event.
-
-```yaml
-time_frame: 28d
-data_source: redis_hll
-instrumentation_class: 'Gitlab::Usage::Metrics::Instrumentations::RedisHLLMetric'
-options:
-  events:
-    - i_quickactions_approve
-```
-
-## Generic metrics
-
-[Example of a merge request that adds a generic metric](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60256).
-
-```ruby
-module Gitlab
-  module Usage
-    module Metrics
-      module Instrumentations
-        class UuidMetric < GenericMetric
-          value do
-            Gitlab::CurrentSettings.uuid
-          end
-        end
-      end
-    end
-  end
-end
-```
-
-## Creating a new metric instrumentation class
-
-To create a stub instrumentation for a Service Ping metric, you can use a dedicated [generator](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_generator.rb):
-
-The generator takes the class name as an argument and the following options:
-
-- `--type=TYPE` Required. Indicates the metric type. It must be one of: `database`, `generic`, `redis_hll`.
-- `--ee` Indicates if the metric is for EE.
-
-```shell
-rails generate gitlab:usage_metric CountIssues --type database
-        create lib/gitlab/usage/metrics/instrumentations/count_issues_metric.rb
-        create spec/lib/gitlab/usage/metrics/instrumentations/count_issues_metric_spec.rb
-```
+<!-- This redirect file can be deleted after <2021-10-09>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/development/usage_ping/product_intelligence_review.md

 ---
-redirect_to: 'review_guidelines.md'
-remove_date: '2021-09-16'
+redirect_to: '../service_ping/review_guidelines.md'
+remove_date: '2021-10-09'
 ---
 
-This file was moved to [another location](review_guidelines.md).
+This file was moved to [another location](../service_ping/review_guidelines.md).
 
-<!-- This redirect file can be deleted after <2021-09-16>. -->
+<!-- This redirect file can be deleted after <2021-10-09>. -->
 <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/development/usage_ping/review_guidelines.md

 ---
-stage: Growth
-group: Product Intelligence
-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
+redirect_to: '../service_ping/review_guidelines.md'
+remove_date: '2021-10-09'
 ---
 
-# Service Ping review guidelines
+This file was moved to [another location](../service_ping/review_guidelines.md).
 
-This page includes introductory material for a
-[Product Intelligence](https://about.gitlab.com/handbook/engineering/development/growth/product-intelligence/)
-review, and is specific to Service Ping related reviews. For broader advice and
-general best practices for code reviews, refer to our [code review guide](../code_review.md).
-
-## Resources for reviewers
-
-- [Service Ping Guide](index.md)
-- [Metrics Dictionary](metrics_dictionary.md)
-
-## Review process
-
-We recommend a Product Intelligence review when a merge request (MR) touches
-any of the following Service Ping files:
-
-- `usage_data*` files.
-- The Metrics Dictionary, including files in:
-  - [`config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/config/metrics).
-  - [`ee/config/metrics`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/config/metrics).
-  - [`dictionary.md`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/usage_ping/dictionary.md).
-  - [`schema.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/metrics/schema.json).
-- Product Intelligence tooling. For example,
-  [`Gitlab::UsageMetricDefinitionGenerator`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/generators/gitlab/usage_metric_definition_generator.rb)
-
-### Roles and process
-
-#### The merge request **author** should
-
-- Decide whether a Product Intelligence review is needed.
-- If a Product Intelligence review is needed, add the labels
-  `~product intelligence` and `~product intelligence::review pending`.
-- Assign an
-  [engineer](https://gitlab.com/groups/gitlab-org/growth/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) from the Product Intelligence team for a review.
-- Set the correct attributes in the metric's YAML definition:
-  - `product_section`, `product_stage`, `product_group`, `product_category`
-  - Provide a clear description of the metric.
-- Update the
-  [Metrics Dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/usage_ping/dictionary.md) if needed.
-- Add a changelog [according to guidelines](../changelog.md).
-
-#### The Product Intelligence **reviewer** should
-
-- Perform a first-pass review on the merge request and suggest improvements to the author.
-- Check the [metrics location](index.md#1-naming-and-placing-the-metrics) in
-  the Service Ping JSON payload.
-- Add the `~database` label and ask for a [database review](../database_review.md) for
-  metrics that are based on Database.
-- For tracking using Redis HLL (HyperLogLog):
-  - Check the Redis slot.
-  - Check if a [feature flag is needed](index.md#recommendations).
-- For a metric's YAML definition:
-  - Check the metric's `description`.
-  - Check the metric's `key_path`.
-  - Check the `product_section`, `product_stage`, `product_group`, and `product_category` fields.
-    Read the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
-  - Check the file location. Consider the time frame, and if the file should be under `ee`.
-  - Check the tiers.
-- Approve the MR, and relabel the MR with `~"product intelligence::approved"`.
-
-## Review workload distribution
-
-[Danger bot](../dangerbot.md) adds the list of changed Product Intelligence files
-and pings the
-[`@gitlab-org/growth/product-intelligence/engineers`](https://gitlab.com/groups/gitlab-org/growth/product-intelligence/engineers/-/group_members?with_inherited_permissions=exclude) group for merge requests
-that are not drafts.
-
-Any of the Product Intelligence engineers can be assigned for the Product Intelligence review.
+<!-- This redirect file can be deleted after <2021-10-09>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/raketasks/index.md

@@ -46,7 +46,7 @@ The following Rake tasks are available for use with GitLab:
 | [Repository storage](../administration/raketasks/storage.md) | List and migrate existing projects and attachments from legacy storage to hashed storage. |
 | [Uploads migrate](../administration/raketasks/uploads/migrate.md) | Migrate uploads between local storage and object storage. |
 | [Uploads sanitize](../administration/raketasks/uploads/sanitize.md) | Remove EXIF data from images uploaded to earlier versions of GitLab. |
-| [Service Data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-service-ping) | Generate and troubleshoot [Service Ping](../development/usage_ping/index.md). |
+| [Service Data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-service-ping) | Generate and troubleshoot [Service Ping](../development/service_ping/index.md). |
 | [User management](user_management.md)                 | Perform user management tasks. |
 | [Webhooks administration](web_hooks.md)               | Maintain project webhooks. |
 | [X.509 signatures](x509_signatures.md)                | Update X.509 commit signatures, which can be useful if the certificate store changed. |

doc/user/admin_area/settings/usage_statistics.md

@@ -69,7 +69,7 @@ sequenceDiagram
 
 ## Service Ping **(FREE SELF)**
 
-See [Service Ping guide](../../../development/usage_ping/index.md).
+See [Service Ping guide](../../../development/service_ping/index.md).
 
 ## Instance-level analytics availability