feat/vcs info by alanpeixinho · Pull Request #1998 · kernelci/dashboard

alanpeixinho · 2026-07-17T17:17:59Z

What it is

Shows the deployed version (git describe --tags --always, uses tag if present, otherwise uses short commit) at the bottom of the sidebar, so we can tell which build is running even when drift is backend-only.

How to test

Dev

Start frontend with pnpm dev
Sidebar version should match git describe --tags --always --dirty.
Clicking on the version should redirect you to the repository (in a specific version, or to the root if not a published version).

Docker

Use DASHBOARD_VERSION=$(git describe --tags --always) docker compose build dashboard.
Sidebar version should match DASHBOARD_VERSION.
Clicking on the version should redirect you to the repository (in a specific version, or to the root if not a published version).

Closes #1611

alanpeixinho · 2026-07-20T11:38:43Z

felipebergamin · 2026-07-20T11:59:19Z

          file: ./dashboard/Dockerfile
          push: true
+          build-args: |
+            VITE_APP_VERSION=${{ steps.version.outputs.value }}


just a nit: your commit message says VITE_VERSION but actually is VITE_APP_VERSION

mentonin · 2026-07-20T18:35:16Z


+      - name: Compute app version
+        id: version
+        run: echo "value=$(git describe --tags --always)" >> "$GITHUB_OUTPUT"


Can we use a descriptive name here?

Absolutelly. Do you have any suggestion?

Do you have any suggestion?

version or repo_version or app_version or APP_VERSION (or equivalent if you decide to change APP_VERSION)

mentonin · 2026-07-20T18:40:49Z

            context: .
            dockerfile: ./dashboard/Dockerfile
+            args:
+                VITE_APP_VERSION: ${APP_VERSION:-}


Why mix APP_VERSION and VITE_APP_VERSION?

The VITE_ prefix is required by VITE.
But, on our own variables, I would rather keep them agnostic (if we ever change vite).

In that case, I would prefer FRONTEND_VERSION or DASHBOARD_VERSION

Also, use APP_VERSION as the container ARG/ENV, and set VITE_APP_VERSION inside the container, so we only interact with "our" variable when building (e.g. on the deploy-containers workflow)

The VITE_ prefix is required by VITE. But, on our own variables, I would rather keep them agnostic (if we ever change vite).

some correction here: we can change the naming here, so I went with DASHBOARD_VERSION for the app, we only need to keep the VITE_ prefix for the inner env variable.

Also changed to VITE_DASHBOARD_VERSION to keep consistent.

mentonin · 2026-07-21T22:05:27Z

Can we make this a link to our repo? Maybe a permalink to the specific version, if not dirty

alanpeixinho · 2026-07-22T14:31:49Z

Can we make this a link to our repo? Maybe a permalink to the specific version, if not dirty

Linking to the proper version on our repo.
If we are in a dirty version, or do not have a proper version, we go to the root of our repo.

mentonin

LGTM, just needs to rebase to solve conflicts

alanpeixinho · 2026-07-24T14:50:17Z

LGTM, just needs to rebase to solve conflicts

Done.

* Include a VITE_APP_VERSION derived from git describe. * Include frontend sidebar information showing VITE_VERSION. Closes kernelci#1611 Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>

MarceloRobert · 2026-07-27T19:31:29Z

@alanpeixinho I saw that you guys are currently releasing under just a "main" tag, which means that the latest actual tag does not relate to the latest commit, specifically the release/20260513.0 tag.

Quoting the Discord bot on his latest messages,

Deploying production Dashboard with tag main
New Django migrations detected in production deployment of main:
backend/kernelCI_app/migrations/0018_hardwareregistryplatformvendor_and_more.py|backend/kernelCI_cache/migrations/0013_delete_checkoutscache.py|
Production Dashboard deployment successful with tag main

So I'm just thinking if it won't be confusing to have that tag in the dashboard, wouldn't it seem outdated?

MarceloRobert · 2026-07-27T19:35:53Z

          SSH_HOST: ${{ secrets.STAGING_HOST }}
          SSH_KEY: ${{ secrets.STAGING_KEY }}

-  cleanup:


Why remove the cleanup step? is the prune unnecessary? Either way I don't understand how this is related to the PR subject

It was accidental, just a rebase against outdated version. I am updating it now.

alanpeixinho · 2026-07-27T20:24:59Z

@alanpeixinho I saw that you guys are currently releasing under just a "main" tag, which means that the latest actual tag does not relate to the latest commit, specifically the release/20260513.0 tag.

Quoting the Discord bot on his latest messages,

Deploying production Dashboard with tag main
New Django migrations detected in production deployment of main:
backend/kernelCI_app/migrations/0018_hardwareregistryplatformvendor_and_more.py|backend/kernelCI_cache/migrations/0013_delete_checkoutscache.py|
Production Dashboard deployment successful with tag main

So I'm just thinking if it won't be confusing to have that tag in the dashboard, wouldn't it seem outdated?

We are actually using git describe --tags --always, so for a deploy from current main we would get something like release/20260513.0--g — last release tag + commits since + short SHA.

But we could also always include a tag for prod. What you think?

Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>

mentonin · 2026-07-27T22:12:20Z

we could also always include a tag for prod. What you think?

That would be great

MarceloRobert · 2026-07-28T11:12:57Z

But we could also always include a tag for prod. What you think?
@alanpeixinho

I think that ideally the CD that deploys the staging/production would apply the tag automatically (somehow), but I think that it would be good to keep tagging each release as it allows for an easy rollback to "the previous deployment" and would avoid date confusion. Otherwise, my preference would be to use a longer commit hash, but I'm fine with the current layout - having something is better than nothing, I don't want to block this PR for nitpicking.

MarceloRobert

LGTM

felipebergamin reviewed Jul 20, 2026

View reviewed changes

mentonin reviewed Jul 20, 2026

View reviewed changes

alanpeixinho force-pushed the feat/vcs-info branch from 322a825 to c62612f Compare July 21, 2026 17:24

felipebergamin approved these changes Jul 22, 2026

View reviewed changes

alanpeixinho requested a review from mentonin July 23, 2026 20:33

mentonin requested changes Jul 24, 2026

View reviewed changes

alanpeixinho force-pushed the feat/vcs-info branch from 1a7fe3a to 9615af3 Compare July 24, 2026 14:49

alanpeixinho force-pushed the feat/vcs-info branch from 9615af3 to 11483c3 Compare July 24, 2026 14:53

feat: Add git versioning information on UI

107b932

* Include a VITE_APP_VERSION derived from git describe. * Include frontend sidebar information showing VITE_VERSION. Closes kernelci#1611 Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>

alanpeixinho force-pushed the feat/vcs-info branch from 11483c3 to 107b932 Compare July 24, 2026 21:26

alanpeixinho requested a review from mentonin July 24, 2026 21:26

MarceloRobert reviewed Jul 27, 2026

View reviewed changes

fixup! feat: Add git versioning information on UI

9226c27

Signed-off-by: Alan Peixinho <alan.peixinho@profusion.mobi>

mentonin approved these changes Jul 27, 2026

View reviewed changes

MarceloRobert approved these changes Jul 28, 2026

View reviewed changes

Uh oh!

Conversation

alanpeixinho commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What it is

How to test

Dev

Docker

Uh oh!

alanpeixinho commented Jul 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alanpeixinho Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mentonin commented Jul 21, 2026

Uh oh!

alanpeixinho commented Jul 22, 2026

Uh oh!

mentonin left a comment

Choose a reason for hiding this comment

Uh oh!

alanpeixinho commented Jul 24, 2026

Uh oh!

MarceloRobert commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alanpeixinho commented Jul 27, 2026

Uh oh!

mentonin commented Jul 27, 2026

Uh oh!

MarceloRobert commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MarceloRobert left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

alanpeixinho commented Jul 17, 2026 •

edited

Loading

alanpeixinho Jul 21, 2026 •

edited

Loading

MarceloRobert commented Jul 27, 2026 •

edited

Loading

MarceloRobert commented Jul 28, 2026 •

edited

Loading