Mike Turley mturley

Green Scrum: Cypress Mock Test Conversion Report

Prompt

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

Catalog Abstraction Analysis: Model Catalog vs MCP Catalog

TL;DR

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

Claude Code Session Export

Exported: 2026-01-28 17:50:42

User

2026-01-28 18:03:44

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:

We release a transitional compatibility-version of PF4 that is identical to the last PF4 version except for the addition of .pf-v-4 version classes on every component/layout style rule.
- This is technically a breaking change for core CSS/HTML consumers, but React consumers could simply upgrade the packages and not have to change their usage at all (component APIs would remain identical, the rendered DOM would match the new CSS).
If we are adhering to proper BEM classes for descenant elements of a component/layout, we should only need to apply this special class to the top of each component/layout unless we need to suppo

OpenShift Console Extension Types

console.action/filter
console.action/group
console.action/provider
console.action/resource-provider
console.alert-action
console.catalog/item-filter
console.catalog/item-metadata
console.catalog/item-provider

This is copied from https://unpkg.com/browse/@openshift-console/[email protected]/doc/console-extensions.md Pasted here to render the markdown for easier reference before it is published somewhere official.

OpenShift Console Extension Types

console.action/filter
console.action/group
console.action/provider

Hi guys, let me know if there is a more appropriate channel for this but I figured we could have a place for async discussion around the Kogito PF stuff within UXD.

For those who want to set up and run the Kogito UI code locally, it's pretty simple. Here's how you can pull down the branches I've been working on with Ajay:

git clone https://github.com/kiegroup/kogito-apps
cd kogito-apps
git remote add mturley https://github.com/mturley/kogito-apps
git fetch mturley
git checkout KOGITO-new-tabledesign

Imperative vs Declarative Programming

The Value of React for Developers

Writing code for what we want the page to do, not how we want the browser to do it.

Basic concepts

I've been working on how to try and explain the fundamental difference between the following two concepts of how programming the interactions on a web page can be done. It's important to grasp both in order to understand the main benefit of React from a developer's perspective. There are also design benefits of React such as the ability to reuse and compose isolated components, but that is beyond the scope of this document.

	{
	"$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"

	#!/bin/sh

	minikube config set memory 10240
	minikube config set cpus 4

	minikube stop

	minikube delete

	minikube start --addons=dashboard --addons=ingress --addons=olm