GitLab Version - Refactor API call to backend
What does this MR do and why?
In response to Slack Thread (internal only): https://gitlab.slack.com/archives/C02PF508L/p1667509138911629
Refactor in preparation for: #379130 (closed)
This change is a refactor to prepare us to expand the Version Check Application. Right now the app simply shows a badge when a status is returned. Moving forward we will be showing an Alert and/or Modal for a Security related upgrade. With the approach to the alert and modal we will be adding some elements that show up and are non-dismissible at the Global level. This means that we will always need to know the status of the current GitLab instance version.
This got me thinking as to if having a post-render API request that always fires for any sys-admin on any page made sense. Instead now the app will render already knowing this information since we need to always know it now.
About Version Check
- Data is stored in separate application: version-gitlab-com
- Data is fetched via this External API and then stored in ReactiveCache
- Subsequent requests get fetched from ReactiveCache until it invalidates itself and data is refetched from API
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
No visual changes
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.
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/link 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.