Add optional url query param for filtering regressed tests by component #3061
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Pipeline controller notification For optional jobs, comment |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dgoodwin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
…id tables - Replace native MUI GridToolbar with Sippy's custom GridToolbar component - Add filterModel state managed via query parameters (regressedModalFilters and regressedModalTestFilters) - Implement addFilters function for adding filters to existing filter items - Pass filter state through componentsProps.toolbar as per Sippy's pattern - Clear filter query parameters when switching between modal tabs - Enable client-side filtering mode for both RegressedTestsPanel and TriagedRegressionTestList This makes the filtering behavior consistent with other DataGrid tables in Sippy (JobTable, TestTable, etc.) and allows filters to persist in URLs when shared.
Member
|
Its a pre-existing problem but these don't use Sippy's standard GridToolbar, which allows multi-filtering and query params. dgoodwin#4 is cursor's attempt at fixing this; seems to sort of work if you want to try it and clean up that version The filterModel JSON isn't pretty, especially to generate in alerts, but it is consistent with sippy in general |
The filterModel needs to be passed both to the DataGrid component itself (to apply the filters) and to the toolbar (to display the filter UI). Previously we only passed it to the toolbar, so filters weren't actually being applied to the data.
MUI's built-in client-side filtering only supports single filters. Since we're working with pre-loaded data in the modal and Sippy's filter system supports multiple filters with AND/OR operators and NOT modifiers, we need to manually filter the rows. Added applyFilters() function that: - Supports multiple filter items with AND/OR link operators - Handles all filter operators (contains, equals, startsWith, endsWith, comparison operators) - Supports NOT modifier for filters - Uses React.useMemo for performance optimization Now filters pre-filter the data before passing to DataGrid, instead of relying on MUI's limited built-in filtering.
Created a new filterUtils module in the datagrid directory that provides: - applyFilterModel(): Main function to filter data based on Sippy's filter model - evaluateFilter(): Single filter evaluation logic - useFilteredData(): React hook for convenience (optional) This removes code duplication between RegressedTestsPanel and TriagedRegressionTestList, and makes the filtering logic reusable by any component that needs client-side filtering with Sippy's advanced filter system. Benefits: - DRY: Eliminates ~140 lines of duplicated code - Maintainability: Single source of truth for filter logic - Consistency: Ensures all components filter data the same way - Documentation: Includes comprehensive documentation with examples The utility supports: - Multiple filters with AND/OR operators - NOT modifier for negating filters - All Sippy filter operators (contains, equals, startsWith, endsWith, etc.) - Numeric comparison operators (>, >=, <, <=) - Performance optimization via React.useMemo
Created GridToolbarClientAutocomplete component that extracts unique values from pre-loaded data instead of making API calls. This is perfect for modals where all data is already in memory. Features: - Extracts unique values from any field in the dataset - Handles array fields (like variants) by flattening values - Sorts suggestions alphabetically - Works with the same filter UI as server-side autocomplete - Zero network overhead Updated GridToolbarFilterItem to automatically choose between: - Client-side autocomplete (when autocompleteData is provided) - Server-side autocomplete (when no data is provided) Added autocomplete support to modal tables: - RegressedTestsPanel: component, capability, test_name, test_suite - TriagedRegressionTestList: test_name, release The autocomplete seamlessly integrates with Sippy's custom filter system, supporting all filter operators, NOT modifier, and AND/OR logic.
Changed both client-side and server-side autocomplete components to use freeSolo mode instead of disableClearable. This allows users to: - Type any partial string for 'contains' filters - Still get autocomplete suggestions from the data/API - Not be restricted to only selecting from dropdown options This is essential for filters like 'contains', 'startsWith', etc. where users need to search for partial matches that may not be in the autocomplete suggestions. Both components now handle: - String values (typed by user) - Object values (selected from dropdown) - Proper onChange and onInputChange events
Added regressedModalFilters and regressedModalTestFilters to the uiOnlyParams list in getReportParams(). These parameters control the modal's internal filter state and should not trigger a full page data reload. Previously, changing filters in the modal would cause reportParams to change, triggering the useEffect that refetches all component readiness data and reloads the entire page. Now these UI-only parameters are properly excluded from the report params calculation. This fix makes tab switching and filtering instantaneous within the modal, as they only affect the modal's internal state without triggering expensive data refetches.
Removed filter parameter clearing from handleTabChange. When users switch between tabs (Unresolved, Untriaged, Triaged, All), their applied filters now persist instead of being reset. The tab handler still resets pagination (page number) and row selection as those are tab-specific, but keeps the filter parameters so users can maintain their filter criteria across all tabs. This provides a better UX - if you filter for a specific component or test name, you probably want to see that filter applied across all tabs.
Implemented full filtering and quick search support for TriagedRegressions table, matching the functionality already added to RegressedTestsPanel and TriagedRegressionTestList. Changes: - Added filterModel state with query parameter (triageFilters) - Implemented addFilters() for filter management - Implemented requestSearch() for quick search functionality - Quick search filters on 'description' field for triage entries - Quick search filters on 'test_name' field for test lists - Applied client-side filtering using shared filterUtils - Added autocomplete support for 'description' and 'type' fields - Added triageFilters to uiOnlyParams to prevent page reloads All three DataGrid tables in the Regressed Tests modal now have: ✓ Multi-filter support with AND/OR operators ✓ Client-side autocomplete with free-form text input ✓ Quick search box for rapid filtering ✓ Query parameter persistence ✓ No page reloads when filtering/searching
Added autocomplete support to all string fields that benefit from it: RegressedTestsPanel: - component, capability, test_name, test_suite, variants TriagedRegressionTestList: - test_name, release, variants TriagedRegressions: - description, type, bug_state, bug_version, release_blocker Marked non-filterable (filterable: false) for fields where filtering doesn't make sense: - Date/time fields (regression, last_failure, opened, last_change, etc.) - Action/icon fields (triage checkbox, status icons, details links) - ID fields (test_id) - URL fields (jira links) This cleans up the filter menu to only show fields users would actually want to filter on, while providing autocomplete suggestions for all string-based filters.
The client-side autocomplete was showing '[object Object]' for fields
that use valueGetter to transform data (like variants, which converts
{ Platform: 'aws', Architecture: 'amd64' } into 'Platform:aws Architecture:amd64').
Changes:
- GridToolbarFilterItem now extracts and passes the valueGetter from column config
- GridToolbarClientAutocomplete now uses valueGetter when available to get
the display value instead of stringifying the raw field value
- Added check to filter out '[object Object]' strings from suggestions
- Updated PropTypes to include valueGetter
Now autocomplete for variants shows proper formatted strings like
'Platform:aws Architecture:amd64' instead of '[object Object]'.
Removed autocomplete from the variants field since it doesn't make sense to autocomplete on the full formatted string when users want to search for individual variant values like 'aws' or 'amd64'. For TriagedRegressionTestList, added a valueGetter that joins the variants array into a space-separated string. This allows filtering to work on the string representation (e.g., searching for 'aws' will match rows containing that variant). Now users can: - Filter variants with 'contains aws' to find all tests with aws platform - Filter variants with 'contains amd64' to find all tests with amd64 arch - Type any partial variant value without being restricted to autocomplete The valueGetter ensures filtering works on the formatted string while renderCell still displays it properly (newline-separated).
This reverts commit b7b600c.
Add query parameter filtering support to Regressed Tests modal DataGrid tables
|
Scheduling required tests: |
Contributor
|
@dgoodwin: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
openshift-merge-robot
added
the
needs-rebase
Contributor
|
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assisted-by: Cursor AI
This is not hooked up to anything, you have to know to add it to your URL, this is being done for alert URLs to link directly to the regressions for the alerting component.
It could be a lightweight alternative to the drilldown mechanism which cache misses, is expensive, and slow, but we weren't sure we're ready to nuke that yet. Will leave it to TRT to decide if and how this gets exposed in the actual UI.