Skip to content

Move logic for archived version banner to the frontend

Sarah German requested to merge 1330-archive-banner into main

What does this MR do and why?

When rendering the Archived Version banner, the site needs to be able to determine if this instance of the site is either the pre-release ("next") or the most recent stable version ("current"). We intend to only show the banner for versions older than current or next.

However, we have a long-standing bug with this that was introduced when we started using the main branch's versions.json file as the SSoT for all online copies of the site: our backend code doesn't always return the right result when checking if it's current or next. This is because backend code only runs at build time, and the current status changes over time.

So, there are two problems we run into, at different times of the version's lifecycle:

  1. current initially has incorrect banner visibility because when the the release is cut, versions.json contains information that's off by one: as next becomes current and pipeline jobs are creating the Docker image, versions.json on the site says that current is still next (this can all vary based on timing of MRs during the release process, and whether or not anything gets backported to the cut release)
  2. current-1 is not correct because the Docker images are snapshots in time, and unless we rebuild the image (e.g, backport something), those don't change to notice that they're no longer current.

This MR moves logic we use for controlling the archive banner's visibility to the frontend. This way, we can check the instance's version against versions.json on page load rather than at build time, so it's always up-to-date, and it's not subject to changing based on when the site gets recompiled.

In an environment where we cannot load versions.json for some reason (e.g, an air-gapped self-hosted copy of the site), we fall back to showing the banner.

Closes #1330 (closed) (for real this time)

Screenshots, screen recordings, or links to review app

Should not see the banner:

Before (v16.5) After (v16.5)
image image

Should see the banner:

Before (v16.4) After (v16.4)
image image

How to set up and validate locally

This takes a few compiles to validate locally. 🙈 ⌛

  1. Configure a local GitLab Docs environment: https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/setup.md.
  2. Check out this branch.
  3. Run a compile as a version older than the current version: make clean && CI_COMMIT_REF_NAME="16.4" make view
  4. View an internal content page and verify the banner does appear.
  5. Run a compile as the current version: make clean && CI_COMMIT_REF_NAME="16.5" make view
  6. View an internal content page and verify the banner does not appear.
  7. Run a compile as the next version: make clean && make view
  8. View an internal content page and verify the banner does not appear.

Merge request acceptance checklist

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

Edited by Evan Read

Merge request reports