Return or display Gitlab version if GITLAB_KAS_VERSION is a SHA

What does this MR do and why?

Gitlab::Kas.version and Gitlab::Kas.version_info are called when the API or frontend needs to display the KAS semantic version.

Both Gitlab::Kas.version and Gitlab::Kas.version_info are based on the contents of the GITLAB_KAS_VERSION file.

We want to support the possibility of the content of the GITLAB_KAS_VERSION being a SHA. In this situation, Gitlab::Kas.version and Gitlab::Kas.version_info will be based on the Gitlab version, with the SHA as the suffix.

Affected areas

These are the areas in the code base that call Gitlab::Kas.version or Gitlab::Kas.version_info

Method Call Point	Has specs?	frontend or API affected	What to display if KAS version is SHA
ClustersHelper#js_clusters_list_data	Yes	Project -> Operate -> Clusters page	For version checking: Gitlab version For installing an agent: Gitlab version with 0 as the patch version[1]
ClusterAgentsHelper#js_cluster_agent_details_data	Yes	Project -> Operate -> Clusters -> Cluster page	For installing an agent: Gitlab version with 0 as the patch version[1]
app/views/admin/dashboard/index.html.haml	Yes	Admin Area -> Dashboard page	GitLab version
InstanceMetadata::Kas	Yes	REST API: /api/v4/metadata/ and /api/v4/version GraphQL: metadata query Note: the API endpoints make use of the GraphQL metadata query Call stack: Types::QueryType -> Resolvers::MetadataResolver -> InstanceMetadata -> InstanceMetadata::Kas -> Gitlab::Kas.version	GitLab version + SHA, e.g.: 17.0.0+5bbaac6e3d907fba9568a2e36aa1e521f589c897

[1] - For the command to install the Gitlab agent, we use the Gitlab version with a patch of 0 because the Gitlab version and KAS versions are only the same up to the minor version (which is based on the milestone). The patch versions are based on fixes specific to the repository, so they would rarely ever be the same.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Frontend

Expand for screenshots

In the following examples, these are the contents of the version files:

$ cat VERSION # this is where the GitLab version is based on
> 17.2.5

$ cat GITLAB_KAS_VERSION # this is where the KAS version is based on
> 5bbaac6e3d907fba9568a2e36aa1e521f589c897

Clusters pages

The KAS version info is used to compare the running agent's KAS version (when the agent was registered) vs the latest KAS version (based on ClustersHelper#js_clusters_list_data). If the running agent's KAS version is older than the latest KAS version, a warning pops up. In the example below, the running agent's KAS version is 16.11.0-rc3 while the latest KAS version is 17.0.0.

Clusters List page - version checking

Clusters List page - registering an agent

Cluster Agent page - registering an agent

Admin Dashboard page

GraphQL and REST API calls

Expand for screenshots

$ cat VERSION # this is where the GitLab version is based on
> 17.0.0

$ cat GITLAB_KAS_VERSION # this is where the KAS version is based on
> 5bbaac6e3d907fba9568a2e36aa1e521f589c897

GraphQL Query

REST API GET /api/v4/metadata

REST API GET /api/v4/version

How to set up and validate locally

For areas not requiring a GitLab agent setup

Setup

Change the contents of your GITLAB_KAS_VERSION file to a SHA, example 5bbaac6e3d907fba9568a2e36aa1e521f589c897

Testing

• To check the Admin page, go to Admin Area -> Dashboard

• To check the API endpoints

  1. Generate a personal access token

  2. Call the /api/v4/metadata endpoint

     curl -k -X GET "https://gdk.test:3443/api/v4/metadata" --header "PRIVATE-TOKEN: $ACCESS_TOKEN" \
     | json_pp -json_opt pretty,canonical

  3. Call the /api/v4/version endpoint

     curl -k -X GET "https://gdk.test:3443/api/v4/version" --header "PRIVATE-TOKEN: $ACCESS_TOKEN" \
     | json_pp -json_opt pretty,canonical

• To check GraphQL

  1. Go to the GraphQL explorer: <your-local-gitlab-url>/-/graphql-explorer

  2. Run the following query:

     query {
       metadata {
         kas {
         version
         }
       }
     }

For areas requiring a GitLab agent setup

Setup

1. Make sure that your VERSION and GITLAB_KAS_VERSION is unchanged, ie it matches what's on master.
2. Register a GitLab agent
3. Make sure that your agent is running:
   • Go back to your clusters page (Project -> Operate -> Kubernetes Clusters)
   • Verify that the agent is listed, with a status of connected and a version info under the version column
4. Once you've made sure that your agent is running:
   • Update the VERSION file to a future version/milestone with a patch, e.g.: 17.2.5
   • Update the GITLAB_KAS_VERSION file with a SHA, e.g.: 5bbaac6e3d907fba9568a2e36aa1e521f589c897
5. Restart your the Gitlab rails app (to ensure rails is reading the updated file contents)

Testing

1. To test the Clusters list - version checking

   • Go back to your clusters page (Project -> Operate -> Kubernetes Clusters)
   • Under the version info column, verify that there is a warning symbol next to the version info
   • Hovering over the warning symbol, you should see a warning message that displays the latest version (this should be the version you've set in the VERSION file)

2. To test the Clusters list - agent installation

   • Go back to your clusters page (Project -> Operate -> Kubernetes Clusters)
   • Click the "Connect a cluster" button
   • In the helm command to install an agent, verify that the image.tag is the content of the VERSION without the patch. For example, if the version 17.2.5, it should be image.tag=v17.2.0.

3. To test the Cluster page

   • Navigate to the individual page of the agent you created
   • Go to the "Access tokens" tab and click "Create a token"
   • In the helm command to install an agent, verify that the image.tag is the content of the VERSION without the patch. For example, if the version 17.2.5, it should be image.tag=v17.2.0.

---

Related to #456414 (closed)