Skip to content

feat: introduce hardware listing versioning and update routing#1743

Merged
gustavobtflores merged 2 commits intokernelci:mainfrom
gustavobtflores:feat/hardware-page-featflag
Feb 12, 2026
Merged

feat: introduce hardware listing versioning and update routing#1743
gustavobtflores merged 2 commits intokernelci:mainfrom
gustavobtflores:feat/hardware-page-featflag

Conversation

@gustavobtflores
Copy link
Copy Markdown
Contributor

@gustavobtflores gustavobtflores commented Feb 11, 2026

Description

Add a feature flag to switch the Hardware listing between v1 and v2, and refactor route/search handling to be type-safe and avoid hardcoded route strings

Changes

  • Add VITE_FEATURE_FLAG_HARDWARE_LISTING_VERSION and document it in .env.example and README.md
  • Introduce a typed HardwareListingRoutesMap and pass route/search sources through Hardware pages and API hooks
  • Update hardware routes so /_main/hardware renders v1 or v2 based on the feature flag (while keeping /_main/hardware/v1 working)

How to test

  1. Set VITE_FEATURE_FLAG_HARDWARE_LISTING_VERSION=v1, start the dashboard, open /hardware and confirm you see the v1 listing (and no “old page” banner).
  2. Set VITE_FEATURE_FLAG_HARDWARE_LISTING_VERSION=v2, restart, open /hardware and confirm you see the v2 listing (and no “new page” banner).
  3. Open /hardware/v1 and confirm it still renders the v1 listing and URL/search params (origin, interval, search) behave as before.
  4. Open /hardware/v2 and confirm it renders the v2 listing and URL/search params (origin, interval, search) behave as expected.

@gustavobtflores gustavobtflores changed the title feat(hardware): introduce hardware listing versioning and update routing feat: introduce hardware listing versioning and update routing Feb 11, 2026
@gustavobtflores gustavobtflores self-assigned this Feb 11, 2026
@gustavobtflores gustavobtflores added the Frontend Most or all of the changes for this issue will be in the frontend code. label Feb 11, 2026
Copy link
Copy Markdown
Collaborator

@MarceloRobert MarceloRobert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add a /v2 route then that page will be accessible even if the env var is set to v1 (because then both /hardware and /hardware/v1 will point to v1, not being able to see v2). Otherwise there's also no point in doing all that mapping if they have just a single search/navigate route value for v2

Comment on lines +59 to +64
{hardwareListingVersion !== 'v2' && (
<NewPageBanner
pageNameId="hardwareListing.bannerTitle"
pageRoute="/hardware/v1"
/>
)}
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really show the banner because if you are at v1 then you can't currently see this page, and if you are at v2 then you disable the banner. I think that for now we should always show this banner. On treeListing there's the same mistake actually...

@gustavobtflores gustavobtflores force-pushed the feat/hardware-page-featflag branch from 30d95ba to eeb8673 Compare February 12, 2026 13:18
@gustavobtflores gustavobtflores added this pull request to the merge queue Feb 12, 2026
Merged via the queue into kernelci:main with commit 0a66b9c Feb 12, 2026
7 checks passed
gustavobtflores added a commit to MarceloRobert/dashboard that referenced this pull request Feb 19, 2026
…lci#1743)

* feat(hardware): introduce hardware listing versioning and update routing

* feat(hardware): add /hardware/v2 route
@gustavobtflores gustavobtflores deleted the feat/hardware-page-featflag branch March 30, 2026 18:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Frontend Most or all of the changes for this issue will be in the frontend code.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants