Fix SQL statements for Service Ping metrics returning fallback values
What does this MR do and why?
Related to https://gitlab.com/gitlab-data/analytics/-/issues/15414.
This fixes usage_activity_by_stage.manage.events
, counts.issues_created_gitlab_alerts
, counts.issues_created_manually_from_alerts
and counts.ci_internal_pipelines
metrics to return correct SQL statements for Service Ping SQL query reports.
This previously returned -1 because the metrics have been overridden in Gitlab::UsageData
to a hardcoded fallback value, but it was not adjusted for Gitlab::UsageDataQueries
.
Screenshots or screen recordings
Before in the report from bundle exec rake gitlab:usage_data:dump_sql_in_yaml
:
counts:
ci_internal_pipelines: -1
issues_created_gitlab_alerts: -1
issues_created_manually_from_alerts: -1
usage_activity_by_stage:
manage:
events: -1
After:
counts:
ci_internal_pipelines: SELECT COUNT("ci_pipelines"."id") FROM "ci_pipelines" WHERE
("ci_pipelines"."source" IN (1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15) OR
"ci_pipelines"."source" IS NULL)
issues_created_gitlab_alerts: SELECT COUNT("issues"."id") FROM "issues" INNER JOIN
"alert_management_alerts" ON "alert_management_alerts"."issue_id" = "issues"."id"
WHERE "issues"."author_id" != 99
issues_created_manually_from_alerts: SELECT COUNT("issues"."id") FROM "issues" INNER
JOIN "alert_management_alerts" ON "alert_management_alerts"."issue_id" = "issues"."id"
WHERE "issues"."author_id" != 99
usage_activity_by_stage:
manage:
events: SELECT COUNT(DISTINCT "events"."author_id") FROM "events"
How to set up and validate locally
- Run
bundle exec rake gitlab:usage_data:dump_sql_in_yaml
- Find the SQL statements in the report. They should have SQL statement strings as values instead of
-1
as in the reports above.
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 Piotr Skorupa