Module: GitlabInternalEventsCli::Text::MetricDefiner
- Extended by:
- Helpers::Formatting
- Defined in:
- lib/gitlab_internal_events_cli/text/metric_definer.rb
Constant Summary collapse
- ALL_METRICS_EXIST_NOTICE =
<<~TEXT Looks like the potential metrics for this event either already exist or are unsupported. Check out https://metrics.gitlab.com/ for improved event/metric search capabilities. TEXT
- EVENT_METRIC_DESCRIPTION_INTRO =
<<~TEXT.freeze #{format_info('METRIC DESCRIPTION')} Describes which occurrences of an event are tracked in the metric and how they're grouped. The description field is critical for helping others find & reuse this event. This will be used by Engineering, Product, Data team, Support -- and also GitLab customers directly. Be specific and explicit. #{format_info('GOOD EXAMPLES:')} - Count of analytics dashboard list views - Count of unique users who viewed the analytics dashboard list - Monthly count of unique projects where the analytics dashboard list was viewed - Total count of issue updates #{format_info('SELECTED EVENT(S):')} TEXT
- DATABASE_METRIC_DESCRIPTION_INTRO =
<<~TEXT.freeze #{format_info('METRIC DESCRIPTION')} Describes what is calculated in the metric. The description field is critical for helping others find this metric. This will be used by Engineering, Product, Data team, Support -- and also GitLab customers directly. Be specific and explicit. #{format_info('GOOD EXAMPLES:')} - Count of merge requests - Count of users with admin permissions - Gitlab version of the instance TEXT
- DESCRIPTION_HELP =
<<~TEXT.freeze #{format_warning('Required. 10+ words likely, but length may vary.')} An event description can often be rearranged to work as a metric description. ex) Event description: A merge request was created Metric description: Total count of merge requests created Metric description: Weekly count of unqiue users who created merge requests Look at the event descriptions above to get ideas! TEXT
- NAME_FILTER_HELP =
<<~TEXT.freeze #{format_warning('Required. Max %<count>s characters. Only lowercase/numbers/underscores allowed.')} Metrics with filters must manually define this portion of their key path. Auto-generated key paths for metrics filters results in long & confusing naming. By defining them manually, clarity and discoverability should be better. TEXT
- NAME_CONFLICT_HELP =
<<~TEXT.freeze #{format_warning('Required. Max %<count>s characters. Only lowercase/numbers/underscores allowed.')} Conflict! A metric with the same name already exists: %<name>s TEXT
- NAME_LENGTH_HELP =
<<~TEXT.freeze #{format_warning('Required. Max %<count>s characters. Only lowercase/numbers/underscores allowed.')} Filenames cannot exceed 100 characters. The key path (ID) is not restricted, but keeping them aligned is recommended. If needed, you can modify the key path and filename further after saving. TEXT
- DATABASE_METRIC_NAME_HELP =
<<~TEXT.freeze #{format_warning('Required. Max %<count>s characters. Only lowercase letters, numbers, and underscores are allowed.')} This value becomes the metric's key path (ID) and YAML filename, so it must be snake_case. It is intentionally different from the instrumentation class name you entered earlier: Instrumentation class (Ruby, CamelCase): %<class_name>s Metric name (key/filename): %<suggested_name>s Tip: a good metric name describes the value being measured, not the Ruby class. Press Enter to accept the suggested default, or type your own snake_case name. TEXT
- NAME_REQUIREMENT_REASONS =
{ filters: { text: 'Metrics using filters are too complex for default naming.', help: NAME_FILTER_HELP }, length: { text: 'The default filename will be too long.', help: NAME_LENGTH_HELP }, conflict: { text: 'The default key path is already in use.', help: NAME_CONFLICT_HELP }, database_metric: { text: 'Database metrics have no default name.', help: DATABASE_METRIC_NAME_HELP } }.freeze
- NAME_ERROR =
<<~TEXT.freeze #{format_warning('Input is invalid. Max %<count>s characters. Only lowercase letters, numbers, and underscores are allowed (snake_case). Ensure this key path (ID) is not already in use.')} TEXT
- INSTRUMENTATION_CLASS_INTRO =
<<~TEXT.freeze #{format_info('METRIC INSTRUMENTATION CLASS')} Choose a name for the Ruby class that will be used to calculate the metric. The CLI will scaffold the class file and a matching spec file for you. #{format_info('GOOD EXAMPLES:')} - CountSnippetsMetric - UniqueInstanceIdMetric - SnowplowEnabledMetric TEXT
- INSTRUMENTATION_CLASS_HELP =
<<~TEXT.freeze #{format_warning('Required.')} An instrumentation class is the Ruby class that will be used for calculating the metric. ex) IssuesCountMetric CountSlackAppInstallationsMetric Look at the `lib/gitlab/usage/metrics/instrumentations/` folder to get ideas! TEXT
- INSTRUMENTATION_CLASS_ERROR =
<<~TEXT.freeze #{format_warning('Input is invalid. Only lowercase/uppercase letters are allowed.')} TEXT
- OPERATION_INTRO =
<<~TEXT.freeze #{format_info('METRIC OPERATION')} Choose how the metric should derive its value from the database relation. See the database metrics documentation for details: https://docs.gitlab.com/development/internal_analytics/metrics/metrics_instrumentation/#database-metrics TEXT
- DATABASE_INSTRUMENTATION_FILES_NEXT_STEPS =
<<~TEXT.freeze - Fill in the ActiveRecord relation inside the generated instrumentation class. - Adjust `expected_value` and `expected_query` in the generated spec to match your relation. - Reference: #{format_info('https://docs.gitlab.com/development/internal_analytics/metrics/metrics_instrumentation/#database-metrics')} TEXT
Constants included from Helpers::Formatting
Helpers::Formatting::DEFAULT_WINDOW_HEIGHT, Helpers::Formatting::DEFAULT_WINDOW_WIDTH
Method Summary
Methods included from Helpers::Formatting
clear_format, counter, divider, format_error, format_heading, format_help, format_info, format_prefix, format_prompt, format_selection, format_subheader, format_warning, progress_bar