The generic core.action extension at packages/plugin-core/src/extension-points/actions.ts (rendered with packages/plugin-core/src/core/helpers/ExtensibleActions.tsx) allows a host page to pass data to contributed actions through componentProps:
componentProps?: Record<string, unknown>;
These scripts reproduce and compare a model-serving deployment-wizard race caused by duplicate connection-types requests.
With one S3 connection in a project, the wizard auto-selects that connection. If the field-local connection-types response is delayed, the selection can persist an undefined connection type. The deployment succeeds, but its InferenceService omits the opendatahub.io/connection-path annotation.
reproduce-connection-types-race-pr-9772.mjs runs one end-to-end reproduction. It creates an InferenceService, checks whether the connection-path annotation matches the entered path, deletes the resource, and prints connectionPathPersisted.run-connection-types-race-comparison.sh runs the reproducer repeatedly against main and a fix branch, then summarizes pass/fail counts.
| // Generated from source.js using https://caiorss.github.io/bookmarklet-maker/ | |
| // Create a new bookmark and paste this as the URL | |
| javascript:(function()%7Bconst%20waitForRender%20%3D%20()%20%3D%3E%0A%20%20new%20Promise((resolve)%20%3D%3E%20%7B%0A%20%20%20%20setTimeout(()%20%3D%3E%20resolve()%2C%201)%3B%0A%20%20%7D)%3B%0A%0Aconst%20fill%20%3D%20async%20()%20%3D%3E%20%7B%0A%20%20const%20locationField%20%3D%20document.querySelector('%5Bdata-testid%3Dmodel-location-select%5D')%3B%0A%20%20locationField.click()%3B%0A%20%20await%20waitForRender()%3B%0A%20%20const%20uriOption%20%3D%20Array.from(document.querySelectorAll('.pf-v6-c-menu__item-text')).find(%0A%20%20%20%20(e)%20%3D%3E%20e.textContent%20%3D%3D%3D%20'URI'%2C%0A%20%20)%3B%0A%20%20uriOption.click()%3B%0A%20%20await%20waitForRender()%3B%0A%20%20const%20uriField%20%3D%20document.querySelector('%5Bdata-testid%3D%22field%20URI%22%5D')%3B%0A%20%20const%20nativeInputValueSetter%20%3D%20Object.getOwnPropertyDescriptor(%0A%20%20%20%20window.HTMLInputElement.prototy |
This report is the output from this prompt:
Look at the cypress mock tests (not the e2e tests) in the upstream model-registry repo and the ones in odh-dashboard related to the model registry, model catalog and MCP catalog features (green scrum's areas). We have a lot of very heavy cypress tests that take forever to run and are flaky. Think hard and analyze which tests would be better off being rewritten as unit tests or component tests (using jest, react-testing-library, etc) and which ones benefit from being cypress tests. A lot of them are just testing local UI functionality and not really integration across the app, and those may be more efficient and reliable without the overhead of cypress. Make a plan prioritized in multiple phases, starting with low hanging fruit and progressing with a balance of effort and benefit. The plan should be broken down into PRs that are each focused and small enough to be reviewed by a human, we want to avoid
The real duplication is between the Model Catalog and the model-registry MCP Catalog (the gen-ai MCP catalog is a different pattern entirely -- client-side table filtering, not the filterQuery API). These two catalogs share ~70-90% of their structural patterns: context providers, filter state hooks, filter-to-query serialization, active filter chips, gallery layout, and filter sidebar. Some shared components already exist (CatalogStringFilter, EmptyModelCatalogState), but the core plumbing is copy-pasted. The MCP catalog's types and logic are a strict subset of the model catalog's.
Recommended path: Start with three low-effort extractions -- unify filtersToFilterQuery, extract a generic useCatalogFilterState hook, and collapse the duplicate filter types. Then extract shared CatalogFilterSidebar and CatalogActiveFilterChips components. This would reduce spinning up a third catalog from ~3-5 days of copy-rename-re
| { | |
| "$id": "https://kubeflow.org/model-registry/catalog.yaml", | |
| "$schema": "https://json-schema.org/draft/2020-12/schema", | |
| "title": "Model Catalog", | |
| "type": "object", | |
| "properties": { | |
| "source": { | |
| "type": "string", | |
| "description": "The name of the catalog provider.", | |
| "example": "Red Hat" |
I just wanted to write down my thoughts about a possibly-naive but simple approach we could theoretically take to support PF4/PF5/Next component styles existing on the same page.
To be clear: I have not learned much about CSS layers or CSS modules, so this may be better achieved with something fancier. However, this would work without any browser compatibility concerns.
Proposal:
.pf-v-4 version classes on every component/layout style rule.
| #!/bin/sh | |
| minikube config set memory 10240 | |
| minikube config set cpus 4 | |
| minikube stop | |
| minikube delete | |
| minikube start --addons=dashboard --addons=ingress --addons=olm |