GitLab Version - Event naming changes
What does this MR do and why?
Closes #378437 (closed)
Closes #369442 (closed)
Currently the GitLab version check badge tracking events do not follow our best practices defined here: https://docs.gitlab.com/ee/development/snowplow/#structured-event-taxonomy
This change fixes them up as described here: #378437 (closed)
About Version Check Badge
The GitLab Version check badge is a badge that informs users of their instance's version status and the severity of an upgrade if they are behind versions. This badge exists in three places:
- Help Dropdown (? in top right of nav)
- Admin Dashboard (/admin)
- Help Page (/help)
Screenshots or screen recordings
N/A
How to set up and validate locally
Important
- Ensure
Gitlab::CurrentSettings.version_check_enabled
is set to true (it defaults to true) - Version Check uses
ReactiveCache
so the first time you navigate to a place where the badge should be, it may not be in the cache and required a single reload. - Please read note above in the first section about my issues with setting up snowplow locally.
Testing Instructions
- Repeat these steps for the following views
/help
/admin
- Help Dropdown (? in top nav)
- Find the Version Check badge
-
/help
=> At top of page -
/admin
=> In the components card - Help Dropdown => First list item
-
- Ensure that when the badge is rendered the correct tracking event is fired
- Ensure when clicking the badge the correct tracking event is fired
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.
Related to #378437 (closed)
Edited by Zack Cuddy