Skip to content

GitLab Version - Internal Endpoint

Zack Cuddy requested to merge 295266-increase-upgrade-clarity into master

What does this MR do and why?

Sets up endpoint for !74830 (merged)
Creates an internal endpoint to fetch data form the external endpoint implemented here: https://gitlab.com/gitlab-services/version-gitlab-com/-/merge_requests/621

Creates an internal endpoint: /admin/version_check.json

We need a safe way to make an asynchronous call to the external version check endpoint. This way we can protect from any sort of DDOS/high volume causing an instance to load slowly while trying to fetch this data. This internal endpoint will allow us to do just that via a AJAX request from Javascript. That will be implemented in the follow up MR linked above.

This endpoint has two levels of caching since it will exist in the Header Nav and have a high volume of usage for any instance that is used by Admin users.

  1. Client Caching
    • The controller uses expires_in to cache the response on a users browser for 1 minute.
  2. ReactiveCaching
    • The service file uses ReactiveCaching to store the external endpoint's data on the instance to avoid numerous external calls.

There is no/low risk of an invalid cache here as the ReactiveCache uses the Version as the key. So if the instance is upgraded, the version will change and thus the cache will begin using a new key and clear the old one.

Screenshots or screen recordings

Not Logged/Non Admin Empty Cache Valid Cache
Screen_Shot_2021-11-18_at_11.57.59_AM Screen_Shot_2021-11-18_at_11.58.56_AM Screen_Shot_2021-11-18_at_11.59.01_AM

How to set up and validate locally

Important: Since version_check uses ReactiveCaching you will need to "warm the cache up" when testing. This will mean that your first hit on your instance will be null. In the background the cache will be fetched/created async. So after reloading you should see the badge appear.

Important: You must be an Admin user to hit this endpoint

  1. Navigate to /admin/version_check.json while logged in as an admin user
  2. Ensure the response is null (cache is empty)
  3. Navigate to /admin/version_check.json again while logged in as an admin user
  4. Ensure a response is given now that the cache is populated.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #295266 (closed)

Edited by Zack Cuddy

Merge request reports