Stricter validation of metric definitions
What does this MR do and why?
Related to #416666 (closed)
We want to make metrics validation more strict.
To make sure schema.json
will not be growing indefinitely, we also want to split the rules into separate files.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
- Try to create/update a metric into something that doesn't pass the new validations:
- a metric with
internal_events
data_source [eg. update this metric] and any of:-
instrumentation_class
undefined or has value other thanRedisHLLMetric
orTotalCountMetric
-
instrumentation_class
isRedisHLLMetric
andoptions
not being exactly an object with anevents
property that is an array of strings -
instrumentation_class
isRedisHLLMetric
andevents
not being an array of objects having exactlyname
andunique
string properties -
instrumentation_class
isRedisHLLMetric
andevents[x].unique
having a value other than "user.id", "project.id", or "namespace.id"
-
- a metric with
redis_hll
data_source [eg. update this metric] and any of:-
instrumentation_class
other thanRedisHLLMetric
orAggregatedMetric
-
instrumentation_class
asRedisHLLMetric
butoptions
is not exactly an object withevents
property that has an array of strings
-
- a metric with
redis
data_source [eg. update this metric] and any of:-
instrumentation_class
other thanRedisMetric
orMergeRequestWidgetExtensionMetric
-
instrumentation_class
set toMergeRequestWidgetExtensionMetric
butoptions
is not exactly an object withevent
andwidget
string properties -
instrumentation_class
set toRedisMetric
butoptions
is not exactly an object withevent
,prefix
and optionalinclude_usage_prefix
properties
-
- a metric with
- Run a test file, for example
bundle exec rspec spec/lib/gitlab/usage/metric_definition_spec.rb
. - This should raise an error due to invalid metrics:
Gitlab::Usage::MetricDefinition::InvalidError
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Michał Wielich