fix: stabilize workspace kind ordering

[thisis-Shitanshu]

What

Sort WorkspaceKinds by displayName before rendering them in the Create Workspace form, using name as a deterministic tie-breaker.

Why

The WorkspaceKinds API does not guarantee a presentation order, so the order of cards on the Create Workspace page could change between page refreshes.

The frontend owns presentation sorting for WorkspaceKinds, so the selection list should apply a deterministic default order before rendering.

Testing

• Added unit coverage for ordering WorkspaceKinds by displayName

• Added coverage for deterministic ordering when display names are equal

• 454/454 Jest tests pass

• Create Workspace Cypress suite passes 73/73 tests

• Manually verified across repeated page refreshes that the UI consistently renders:

  • JupyterLab
  • RStudio
  • VS Code

  even when the WorkspaceKinds API returns the items in different orders

The full mocked Cypress run has one unrelated failure in workspaces/secretsEdit.cy.ts. The same failure is reproducible on a clean origin/notebooks-v2 checkout.

Related

related: #336
related: #1112

#336 documents the decision to keep paging, sorting, and filtering in the frontend.

#1112 separately tracks duplicate WorkspaceKind requests and is not addressed by this change.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign paulovmr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• workspaces/frontend/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thisis-Shitanshu]

@christian-heusel @andyatmiami PR is up: #1344. Thanks again for the guidance and for helping me validate the direction before implementation. I kept the change focused on deterministic frontend ordering and added regression coverage for the default sort and tie-breaker. Would appreciate your review when you get a chance!

[christian-heusel]

@thisis-Shitanshu great job on your first PR to this repository 🎉

I briefly reviewed your changes, see the comments below 😊

[christian-heusel]

Why did you opt to add the fix add the presentation layer instead of the data layer? 😊 the useWorkspaceKinds() hook is also used in other parts of the code, did you audit them if they suffer from the same issue? Some have other sorting mechanisms, but might be sensible to look at 😊

[thisis-Shitanshu]

Very good point. My initial reason for keeping this in WorkspaceFormKindList came partly from the earlier discussion with @andyatmiami about whether the PatternFly container should own the ordering. We found that Gallery itself doesn't own ordering, and the adjacent Image and PodConfig list components also prepare their ordering before rendering, so I treated this as frontend list/presentation preparation.

After your comment, I audited all production consumers of useWorkspaceKinds():

• WorkspaceFormKindSelection passes the result into the WorkspaceKind card list, which is the flow affected by this issue.
• WorkspaceKinds.tsx applies its own sorting based on the active table sort.
• WorkspaceTable.tsx only uses the result to build the kind/logo lookup.
• useWorkspaceFormData.ts uses it for lookup, so ordering is irrelevant there.

So currently only the Create Workspace flow depends on this default ordering, while one consumer replaces the ordering and the other two are order-insensitive. There will be a small redundant sort for WorkspaceKinds.tsx if we move this into the hook, but here that cost is negligible.

This still seems consistent with the earlier discussion with Andy because the ordering remains in the frontend data-preparation layer rather than being delegated to PatternFly.

I also noticed the duplicate useWorkspaceKinds() / API requests again while auditing this. That's already tracked separately in #1112, so I'd keep that out of this PR and will look at it independently.

[christian-heusel]

/ok-to-test

[thaorell]

a minor comment below